“Thanks” Ben

When it is planned to have the ability to have a bite control on FMS, GNS, … ?

Cheers
Stef

Hi Jean-Luc,

The menu system is _entirely_ fire-walled. You can’t see other plugins menus, they can’t see you, you can’t change them, they can’t change you. So there should be no situation where the menu IDs are not what you expect.

There’s no -new- functionality in the nav APIs for 11.10.

You are right Ben and this is exactly what we do.

Tyler, The suggestion is more about plugins needing to know one other plugin menu, and not wanting to interfere or alter it, just to discover. In the API example I’ve posted, the ID could be ‘poisoned’ (MSB to 1?) and only serve this API purpose and none other.

Mind you, I don’t know much other plugins than ours that contextually change the menu depending on the aircraft changes and other user selections, and we have requests from aircraft vendors to follow these changes live so as to adapt their 3D model live accordingly. The suggestion is just for the sake of completeness for the cases it can help, especially in keeping plugins decoupled from custom-coded inter-plugin and per-plugin signalling schemas, otherwise you are right there are many other ways to do the same.

The new SDK will gives access to the FMC/FMS/GNS to send flight plan to them ?

Cheers
Stef

Jean-Luc, under what conditions do you not know the position of all of your menu items?

The expected use of the APIs is that you’d record your item number from each original item creation if you need to refer to it, e.g. for decorating check-marks.

We’ve actually been really careful to isolate each plugin’s access to the menu system—a policy I don’t see changing any time soon. (In general, “you,” the developer of your plugin, should know a lot more about what’s supported by your plugin than anyone else!) I think the right solution in this case would be for the two plugins to be aware of each other—possibly by looking for things like custom datarefs—and for each to manage its own menu in response to the presence of the other. I realize the realities of the market are such that sometimes plugins get abandoned and such, but we would lose a lot of safety by allowing plugins to manipulate each other’s menus.

Hi Tyler, while you’re at it, you might want to consider a cross-pluggin “XPLMFindMenuItem”. This could work like this:

// returns -1 or menu id.
id = XPLMFindMenuItem( XPLMFindPluginsMenu(), “my plugin menu” );
id = XPLMFindMenuItem( id, “menu sub 2” );
id = XPLMFindMenuItem( id, “item 1” );

[plugins]
– Dataref Editor
– my plugin menu
– menu sub1
– item1
– menu sub2
– item1 // returns this menu id

This could help some plugin specific features to be activated based on some other plugin menu items present or not.

Point taken re: documentation! 🙂

I hope the new XPLMNavigation is on Philipp’s schedule, after the G1000 for 11.10 and visiting several flightsim conventions in Europe 😉