Now comes the revelation that, if these gauges happen to be in a panel which is not being displayed, then the code is not being executed behind the scenes. Wow!
Walter
Not sure if you have something to worry about ...
As best as that I know (that is in all my own XML gauges and the C-coded gauges I use):
It's not relevant for code execution in a gauge whether a 2D-panel window is visible or not.
What IS relevant, is if the 2D-panel window has been made visible at least once after loading the aircraft. Because a gauge in a 2D-panel window isn't loaded until you make the window in which it is defined, is made visible.
After that, the gauge code remains executing, and at the update freq. you have defined.
And this applies to any 2D-panel window, including the main panel window (usually Window00).
As a gauge defined in a VC section of the panel, is ALWAYS loaded and executing at aircraft load; no matter in what view mode you load the aircraft.
This works exactly the same in FS9 and FSX.
So Yes: if you have control logic (e.g. code that should always be executing) as part of a gauge that is defined in a 2D-panel window (because it has a visible pilot-interface), you better split of that code and place it in a no-bitmap gauge in a VC section. Because you cannot predict how the user (in what view mode, and with which 2D-windows opened initially) loads the aircraft.
Part of the confusion probably comes from what one calls "initial"aircraft-load.
If you load an aircraft from the FS menu, by composing a new flight (select an aircraft, select a scenery, etc etc):
Yes, in FS9 the default view is 2D (so the main window00 is loaded; therewith all gauges defined in window00)
In FSX, the default view (2D or VC) depends on the FSX preference setting.
However, if you load an existing flight (or load another aircraft from within an existing flight) it comes up in the current view.
So if this is eg. Spotplane view, the 2D main panel window (and gauges defined in it) are NOT loaded yet.
Unlike gauges defined in the a VC section (Always loaded).
Again, works the same in FS9 and FSX ....
In short, what Tom wrote is correct.
HOWEVER, this is valid for my own XML gauges, and the C-coded gauges I use.
And I'm pretty sure that, as to loading a gauge, the above is true. For whatever type of gauge.
BUT: as to a gauge scheduling/updating it might be different.
That is: may be there is a way that the gauge coder can prevent gauge coded being updated (executing) when the window it's defined in is not visible.
Maybe this is what the <Update> section in an XML does ????
(I never quite understood the meaning/advantage of it).
And maybe, the same is possible in a C-coded gauge (I can't code in C/C++, so I don't know).
IF this would be possible, I can think of a purpose why a designer would want to use that: to prevent framerate-eating by complex gauges when they are not visible.
Can somebody comment on this ??
For reference, I tried all of my loading/executing experiments with Doug Dawson's gauges (like XMLsounds, etc ...).
And those behave exactly the same as my XML gauges (loading/executing/updating wise).
To the OP:
So what you want (setting Lvars by clicking a gauge defined in a 2Dwindow, and read these updates Lvars in another gauge defined in a VC section) is perfectly possible.
If it doesn't work, you're doing something wrong. Copy/paste the code here, and no doubt someone will help ...
Rob