Oh I never thought of that, i assumed the creators of Iris would of already thought about that, and you’ve no need to apologise, it’s fine now!
I did the same thing for my UI, and what do you know… Drum roll, please… it fixed it! Woohoo! Finally, after so long! Thank you so, SO MUCH! I can finally continue working on my game like before and get it released ASAP!!
However, I would like to still be updated about the weird situation of the latest release on the GitHub, where the Assets-to-download is actually an older version of Iris (I’m convinced).
I was wondering what causes the windows to be scaled like this on Mobile/Tablet. I checked the size of the WindowButton and the X is the same as what I set it as, but for some reason, Iris, seems to ignore the fact that I set the Y also, and sets it to an absurd value.
I had the Y set to 375 to begin with, then as a test, went straight up to 1000, and still Iris, for some reason sets it to 75, regardless? Why?
Every time you call a widget which has children, you must also call Iris.End(). If you have an error with somewhere in your code, this issue will show up, so make sure you don’t have any errors within the Iris code. If you make an asynchronous call, Iris will be unable to finish at the end of the frame, and this will error. Also, make sure you don’t accidentally return without properly ending any children.
There’s a new errors page coming on the docs which should help with this.
Sorry for the late reply, for some reason or another, I did not get the notification.
Anyway:
Well, turns out the issue was actually because I was calling functions (when a button was clicked) outside of the Iris.Connect() function, which I don’t understand. However, these functions are asynchronous, so maybe that’s why. I called them in a pcall this time, and that seems to fix it… ish
Also, I know I have to put Iris.End() at the end of some widgets, I am confident I have put it at the end of the necessary ones, as well as Iris.PopConfig() as well, but i could be wrong, so will double-check. I also don’t think it could be errors in my code either. But I could be wrong on that. So I will also double-check that too.
Well, I assume by “asynchronous call” you are referring to pcalls–I have quite a few pcalls in some buttons, when they are clicked, a function gets called, but within a pcall as it could error, when it does error, I don’t return anything as you can see, as that would break Iris.
The docs page is now out, so you can have a look at it. Using a pcall won’t be the issue. Asynchronous means that the code has to yeild for another event, ie. you’re trying to fetch a web site, which takes time, or you are calling task.wait(), both which will take more than a frame to achieve, and so are asynchronous.
It seems brilliant so far! However, I have come across a bug. I’m not sure if this is with the latest update or not, but when closing a window, then reopening it, and repeating that same process, the DisplayOrder of the ScreenGui instance increases by 1 when opening. So my Iris UI DisplayOrder is set to 9, so when opening a Window, it goes from 9 to 10, then 11, 12… etc, etc. You get it.
This is really annoying, as I have to have the DisplayOrder set to 9 in the config, so when it goes above 9, it just makes non-Iris UI completely unusable.
Noticed that a “print” statment was accidentally left in (at least I assume so since it is the only one in the whole of Iris). I made a Pull Request which removes the print.
We are planning on rewriting tables entirely, to make them better suited for more cases and to give you more flexibility.
I think the issue you are having is that the ContentWidth config option is set by default to 65% of the full width, hence why the input boxes do not fill the entire width. You can use something like this, which ensures they fill the entire width: