Getting previous Screen Width and Height in ScreenOrientationChanged

The reason to catch the ScreenOrientationChanged is usually to update the screen layout for the new dimensions of the screen. However this cannot be done directly, as the screen Width and Height getters return the previous size of the screen- before the orientation has changed.
There is an ugly workaround: handle the event 1 ms later using a Timer. Some say it should be 100 ms.. I don't know, 1 ms works on my phone, but will it break on some other device?
Please make the ScreenOrientationChanged event useful for the usual use case. Thank you!

Maybe it is better to set it to 100ms...the difference is almost negligible...and that way you are safer

1 Like

The timer is very slow and needs at least 20-30ms to react. Setting it to 1ms doesn't change anything. I would generally recommend 100ms, at least that's what I've been doing in all my apps for more than 10 years.

Well exactly this is what I'd like to avoid :slight_smile:. Using arbitrary numbers found on the forums; using less straightforward code and workarounds for simple tasks. App Inventor would be even greater to teach programming to beginners if we didn't have to learn so many workarounds so early.

Unavoidable. The world is full of bugs and flaws. Even the people behind the grocery shop's counter call themselves programmer. And even the real programmers do mistakes. They try to finish their programs as soon as possible either by the pressure of their superior or by themselves to be able to start a new job sooner. More jobs more money. And so on...

I don't disagree. But the fact that we can't completely avoid bugs and flaws doesn't mean we shouldn't report and fix some as they are found.
MIT, for instance did quite a good job with Scratch. We could concentrate on the basics without learning too many workarounds and quirks before reaching a more advanced level. I'm writing in the hope AppInventor will get there some time.

You are right but...

hope AppInventor will get there some time.

Maybe in the next 2 decades?!
I have found few bugs 4 years ago. I guess they are still in the system, haven't check. It would just pi$s me off.
IOS development is first priority now for the AI2 team.

It's not a bug. The question is, when will the .ScreenOrientationChanged event fire? The answer is before the Screen.Height and Screen.Width have been detected.

Another question would be, why isn't the event only triggered once the height and width of the screen have been captured? Then you could, however, e.g. ask the question why the TextBox.TextChanged event is not only triggered after the user has finished typing.

Check out this test app:

Clearly, it can be documented as a feature if we feel like. But IMO that makes this feature counter-intuitive. I'm interested in how people use the ScreenOrientationChanged event. Doesn't it always include querying the new screen resolution and working on the new screen layout? Wouldn't most people want to do that in the handler, and get confused when that doesn't work? If so, it's a good idea to make this event fire after the screen layout is actualized. Or is there a use case that I'm missing that requires the event to be handled early?

I don't see the similarity with the TextBox example. One aspect is relevant here though: I can rely on the TextBox.Text property to be up-to-date in the event - I don't have to start a timer to get the new value. And that's good, because I almost always want to work with the new value in the handler.

Good question. I don't know if the event can be made dependent on when the height and width of the screen was detected. But you're right, I can't think of a reason that would make sense either.

Now that you know that, what exactly is the problem? Doesn't this simple query always give us a reliable (even if wrong) result?

This means that orientation-dependent layout adjustments can be made in the ScreenOrientationChanged event. Not true?

True. To be clear, I'm not specifically against using the timer. My problem is the need to use an apparently unnecessary workaround to achieve a routine task.
This is a clever trick, but I'd still go with the timer. That's more straigthforward, and allows me to get the new sizes of other components too, if needed.