Is this a bug when using the Remote Control functionality, or am I interpreting this wrong? I did take note in your manual that Remote Control should be disabled when selecting Departure due to the interactions being required.
Yes, that would how's supposed to work, but I must say we haven't tested it that much, because up to now, all Remote Control implementations we saw so far (Leonardo, FS Labs, Inibuilds A350), use the Remote Control feature fully, by enabling it at the start of the session, and disable it when the session ends.
What the manual was meant to say, is you should Enable/Disable Remote control "on demand", in case you don't want to handle the bi-directional interaction with GSX, making for an easier coding.
However, even if this is (should) be possible, it's still not recommended because, it will work only for as long we don't touch anything in the way GSX works. For example, if we had a new extra step or an immediate dialog at any time in between, your code will break and it would have to be changed to take into account the new dialog, so you would have to momentarily turn off and on again Remote Control.
Also, if you are supposed to continue the procedure later in Remote Control, you would still have to deal with the menu timeout time and the user choice, which is then not much different than implementing the complete Remote Control, where you handle the menus and the replies yourself, so no menus will ever show. Which is also better for users because, if you had to pause remote control each time there's a menu and let it show, what would be the point (or the benefit) or using Remote Control, from the user's point of view ? They'll still see the menus, so not much will change in the end, the main point of the Remote Control was to get rid of the menu entirely, or show them in a different way, for example inside an EFB or a similar instrument in the airplane.
To do this, you should handle the communication with GSX by-directionally, which means reacting to the two events (one for the menu with various values to show depending on the meaning, the other one for the text message, with the value indicating their timeout ) used by GSX to communicate to the "menu" (which in Remote Control is your app) it's time to show a menu, or to show a text message, which will appear as text lines in the "menu" and "tooltip" files in the GSX package.
The C++ sample provided shows how to do this, it's a translation in C++ of the default GSX Toolbar Menu logic, and it's kept purposely very sparse on graphic (it's a text mode console app), so it could be short and easy to follow without any graphic code that would have hindered the logic, and also to make a point you would be free to display the menus in any graphic style you want.
This approach will make your app resistant to any possible future changes in the GSX logic because, in case we'd added a new pop-up menu, or just moved an existing one to appear at a different time, you won't have to make any changes, it will just work and will show the menu no matter what it says and when it pops out.
