GSX CTRL SHIFT F12

[FSLA320User]

i have the same issue, and yes by is also when i press 1-2-3-4 etc. and then open the GSX then is started what i have press bevor
The fix is i must wait 5-10sec. and then open GSX have i right ?

[iuli]

It seems the issue is if you want to press numerical keys (1-9) or something. But also affects Ctr+F12 for GSX menu. Until a solution will arrive, you can use this workaround. Keep pressing CTRL key and after few seconds press F12 (but don't free CTRL key during this) and the menu will stand. I'm using mouse cursor to choose options from the menu, not numerical keys.

[Rafal]

I was just going to post about deboarding starting while boarding when trying to open GSX menu and have discovered this thread.
Glad I am not alone with this problem. As for P3Dv4.2, I have installed both Client and Content and my FSUIPC is an older version (as suggested by other users).

Since Umberto says it has nothing to do with GSX and is LM's bug, it looks like we will have to wait for a few months for P3Dv4.3.
Providing that, of course, LM does fix it.  

[virtuali]

Since Umberto says it has nothing to do with GSX and is LM's bug, it looks like we will have to wait for a few months for P3Dv4.3.

Surely it's a P3D bug. It happens with each and every Simconnect application that has a menu, even with the sample provided in the SDK.

Note that, normally, nothing happens if you just restrain yourself from pressing a numeric key BEFORE opening the menu. Since the numeric keys, by default, are only used by the menu itself, this is not usually a problem.

The problems will start if you assign the numeric keys to some other addon so, each time this other addon sends a numeric key or you press it to trigger it, this will be buffered somewhere, and will auto-select the next Simconnect menu that will open. We initially assumed it was a problem of Chaseplane, because a users reported it started only when starting Chaseplane, and stopped when closing Chaseplane, but the real problem was that he assigned some of the numeric keys to Chaseplane views, so they were sent each time a new view was selected.

So, the best solution, until LM will fix it, is not use the numeric keys for any addons, which is the default. And don't press them manually...

I doubt we'll have to wait months for a new 4.3 version to get this fix, there will be likely an Hotfix which hopefully won't take long.

[Rafal]

Umberto, thank you very much for your detailed answer.
One more question to make sure I get it right, okay?

the best solution, until LM will fix it, is not use the numeric keys for any addons, which is the default. And don't press them manually

Do you mean any numeric key (1-0) including the ones located over keyboard letters, or only keys from the right-side numeric keypad?
Because if the first one, these are usually used when using ATC, both default and some add-on ones like PRO-ATC/X.

[w6kd]

First, should GSX really be crashing when a menu option that is out of range is input, even from a buggy keyboard message handler in P3D?  Seems that it should do a range check and simply disregard out-of-range inputs rather than crashing when an errant value is received.

Second, would it be possible to add an option (configurable in couatl.ini, for example) for GSX menu selections to only be made with mouse clicks on the menu window, disregarding the number keys entirely?  Seems that could bypass the current issue...and frankly, I'd like the ability to deconflict my number keys for other reasons as well.

One other thing...even if one does not press numeric keys before activating the menu, the panels may be doing that, particularly with door commands sent as emulated keypresses by the panel code as "Shift-E" followed by the door number.  

Regards

Bob Scott

[virtuali]

First, should GSX really be crashing when a menu option that is out of range is input, even from a buggy keyboard message handler in P3D?  Seems that it should do a range check and simply disregard out-of-range inputs rather than crashing when an errant value is received.

There wasn't any need to do an "errant value check", because the NORMAL (non bugged) behavior for the Simconnect menu, has always been that, if a menu contains X entries, and you press a key outside its range, the key should not respond.

So yes, we could add such check, which will prevent the GSX error message, but it still won't remove the bug, so key event would still be registered when it shouldn't. IT IS A BUG.

Second, would it be possible to add an option (configurable in couatl.ini, for example) for GSX menu selections to only be made with mouse clicks on the menu window, disregarding the number keys entirely?  Seems that could bypass the current issue...and frankly, I'd like the ability to deconflict my number keys for other reasons as well.

You are assuming we have some kind of control over the Simconnect menu. I'm highlighted in bold, to make sure you understand this is NOT a "GSX menu", it's the standard Simconnect menu, and applications don't have ANY control over how it works. The SIM handles BOTH they  keyboard AND the mouse.

One other thing...even if one does not press numeric keys before activating the menu, the panels may be doing that, particularly with door commands sent as emulated keypresses by the panel code as "Shift-E" followed by the door number.  

That's even more reason why it's urgent LM should fix this as soon as possible. There's no way for us to fix the automatic selection bug, because we cannot possibly know from GSX if the number selection was intentional or not.

I'll repeat it again: the same bug happens with *every* Simconnect application with a menu, including the Sample provided by LM in the SDK!