Beta 3 - Starting Orientation Event Inconsistency

I would imagine this is just the behavior of the device, so this might not be a bug, but it’s really annoying… and if there was a way to artificially induce the event, that’d be great.

On startup, you only get an orientation event if it’s different from your default.

Probably WAI (working as intended), but since we can’t currently obtain the current orientation it sure would be nice if there was simply an orientation event generated at startup even if it’s the same orientation as current.

There are a multitude of reasons why, but mainly it’s because right now the only way around this issue is to hack in a timer that checks to see what my “stored” rotation is after 500ms. This could well be inaccurate if someone was rotating on startup, but it’s the best I can do for correctly initializing my interface orientation for certain parts of my app.

Making the orientation event consistently fire at startup would alleviate the need for any special hacks to obtain this information.

Scott [import]uid: 5659 topic_id: 1007 reply_id: 301007[/import]

Hi Scott,

I use the regular Orientation event and if I start the game in a different orientation than the default one, the event gets fired.
Or do you ment something else?

Michael [import]uid: 5712 topic_id: 1007 reply_id: 2452[/import]

Would being able to query the current orientation resolve your needs?

Something like:

local currentOrientation = system.getInterfaceOrientation()

Incidentally, we have a some high priority bugs like launching in landscape that are related. [import]uid: 26 topic_id: 1007 reply_id: 2456[/import]

@MikeHart - Yes, the point I’m making is if you start in any orientation other than your default assigned orientation you get an event. So one way to allow us to know right from the start what orientation we’re in is to fire that event in all cases.

@walter - Yes, being able to query the current orientation (or at least the starting one) would avert the same issues I’m experiencing.

Thanks,
Scott [import]uid: 5659 topic_id: 1007 reply_id: 2461[/import]

Hi Scott,

maybe I am stupid, but I don’t see your problem. The event gets fired and I think before the first frame event. If not, you are in the default orientation.

Michael [import]uid: 5712 topic_id: 1007 reply_id: 2467[/import]

Well I think I’ve explained it, but let me try again. :slight_smile:

I have certain objects that require an *initial* rotation to orient them based on the current orientation. One specific example is I have a wheel that can be spun and it has a pointer on it. That pointer needs to be rotated *initially* to be “pointing to the right”, regardless of the orientation I’m in. Note this *only* happens at startup, any other time the device is re-oriented it does not get changed.

At present, prior to an orientation event, I do not know what orientation I am in.

So let’s take your example and assume I’m in portrait.

I’ll call my function that initializes my display for portrait.

Everything is fine.

Now let’s say someone starts the app in landscapeLeft.

This is where the wheels come off. There is no way to tell if the orientation event I get at start up is because someone re-oriented while running the app or if it is because this is how the app started initially.

There are two “real” solutions: One is to do what Walter said and provide a way for me to know what orientation the app is starting in so I can properly initialize things and the other is to always fire off an initial orientation event regardless of current orientation in relation to the default.

This is event-driven stuff, so there is no way to initialize for something which will only be called sometimes. Think about this and you’ll see the issue. Say I make a boolean which means “I need to initialize my wheel pointer”… so in my orientation changed function I check that and initialize it if I need to then set it to false. Hey that works great *except* when we start in portrait mode… because there is no initial orientation call, running in portrait mode I’ll “initialize” the wheel pointer if the user happens to re-orient during the app run.

Scott [import]uid: 5659 topic_id: 1007 reply_id: 2472[/import]

I believe this should be fixed in Beta 4: there is now a “system.orientation” property you can query for the current orientation. [import]uid: 3007 topic_id: 1007 reply_id: 2636[/import]

Yup, gonna be testing that tomorrow.

I’ll test that in place of my “timer hack” before I dismantle and switch over to the new auto-rotate stuff so you can mark this as cleared (hopefully). :slight_smile:

Scott [import]uid: 5659 topic_id: 1007 reply_id: 2638[/import]