'service_id' values explained?

[darrenecm]

I'm trying to get a handle on the manner in which the panel system for FS2004 calls C gauge code routines and was wondering if anyone could expand on the following:

#define PANEL_SERVICE_PRE_QUERY 0
#define PANEL_SERVICE_POST_QUERY 1
#define PANEL_SERVICE_PRE_INSTALL 2 // extra_data = resource_handle
#define PANEL_SERVICE_POST_INSTALL 3 // extra_data = resource_handle
#define PANEL_SERVICE_PRE_INITIALIZE 4
#define PANEL_SERVICE_POST_INITIALIZE 5
#define PANEL_SERVICE_PRE_UPDATE 6
#define PANEL_SERVICE_POST_UPDATE 7
#define PANEL_SERVICE_PRE_GENERATE 8 // extra_data = phase
#define PANEL_SERVICE_POST_GENERATE 9 // extra_data = phase
#define PANEL_SERVICE_PRE_DRAW 10
#define PANEL_SERVICE_POST_DRAW 11
#define PANEL_SERVICE_PRE_KILL 12
#define PANEL_SERVICE_POST_KILL 13
#define PANEL_SERVICE_CONNECT_TO_WINDOW 14 // extra_data = PANEL_WND
#define PANEL_SERVICE_DISCONNECT 15 // extra_data = PANEL_WND
#define PANEL_SERVICE_PANEL_OPEN 16
#define PANEL_SERVICE_PANEL_CLOSE 17

Getting a handle on the program flow for C gauge code is essential for me in order to be able to optimise my code. I just need confirmation on exactly when sections of C code are called when using these values in a switch statements. The MS SDK is, as usual, quite useless in this matter. For instance I assumed that the PANEL_SERVICE_PRE_INITIALIZE code was generated once for when a gauge is loaded when an aircraft is selected. Now I hear that it's also generated when you simply switch to and from 2D and 3D virtual views! Is this right? If so the INITIALIZE naming convention is quite counter-intuitive :)

I'm amazed anyone ever discovers how these defines work in the context of the FS2004 panel system seeing as it's part of a hidden system you don't have much control over, coupled with the fact the official SDK is so pitifully documented. For those who have figured these things out, could you share any tips on how you disocvered the inner workings of these service_id values and when they are generated?

I guess I could create a simple gauge that printed text alerts on the screen for each case section that was called, that way you know under what conditions the code sections were processed? I was thinking of doing this but if anyone has already deduced the 'inner workings' of these things already, it would save me a lot of time and potential headaches. Any guidance will be greatly appreciated :)

Grassy arse amigos.

[n4gix]

In general, all of these cases are evalutated twice during any gauge cycle.

The opening case is PANEL_SERVICE_CONNECT_TO_WINDOW, so you can't tell too much about the "order" based on the SDK #define sequence.

The ones that I included in the GDI+ Template are the ones most commonly used. Frankly, many of 'em seem to have no real use at all!

Doug Dawson created a service_id_test gauge about a year or so ago. It's available at http://avsim.com

[matsis]

Any code contained in
PANEL_SERVICE_PRE_UPDATE
section of a c++-gauge is exectued once every gauge update cycle, i.e. 18 times a second.
About
PANEL_SERVICE_PRE_INITIALIZE
I have assumed the same as you up till now. In there I put anything that requires initialzing before the actual gauge code starts to work, especially if sounds are involved and might click/beep away during panel loading because some general definition is not clear yet during gauge loading. However, I have not found such code to hurt during view changes, and I will usually put it within a seperate counter variable that will only be true once right during panel loaeing and never revert back to the status it had at first.
Of the other stuff I have hardly a clue myself, apart from the KILL parts that again are important when having to clear sound handles and such from RAM before gauge code execution is ended.

[darrenecm]

I just tried posting a response in this thread (a long one) and it seems to have gone awol when I clicked on 'Post message'. I didn't see any error messages. This DCForum is quite irritaing at times. No easy formatting, refuses to stay in linear viewing mode (I hate threaded mode's indent-ad-infinitum style) :)

So here it is again, hopefully my original post won't magically appear and create a repeat post.

Anyway. I stumbled across Arne Bartel's sdkbugs.zip file today that had some pertinent information regarding service_id sequences. I've pasted an excerpt at the bottom of this post.

Arne used tabs in the word document for his listing but I couldn't figure out how to apply tab formatting using DCForums poor formatting abilities, so I simply used --- to indent the appropriate lines.

I'm also not sure of the line '// aircraft change' in the document at the end of the two service_id blocks. Should there be another listing showing how things are called when an aircraft is changed. I would have thought 'aircraft change' is the same as 'aircraft selected...or is there a difference?

The information also appears to have been written during the FS2000 era, so the question is whether any changes in FS2004 may mean the information needs to be updated? Can anyone confirm?

My stumbling on sdkbugs.zip also raises the question of whether the gauge programming community really needs a single place to come to in order to find the name and location of all informational material relating to gauge programming. Maybe Bill or one of the other forum moderators could start a 'sticky' thread that brings together a listing of known filenames and locations for all such files? They all seem sequestered away all over the Internet :)

The only information files I know of in addition to sdkbugs.zip are:

idehowto.zip
sd2gau17.zip

Can anyone point me towards any others?

Finally, do all these service_id values actually compare to standard Win32 message ID values as used in general Windows programming? A gauge does exist within a resieable window after all, so I was wondering if, behind all those cryptic macros in the panel SDK that insist on hiding plain C code, the gauge DLL code structure is in fact simply the same as that found when programming your own window code and message handling in Win32?

Thanks for the help guys

- Darren


**** Excerpt from sdkbugs.zip / Author: Arne Bartels****

service_id sequence:

An FS2000 gauge runs through a specific sequence of service_ids (like the FS98 gauges ran through the initialize_routine(),install_routine().....kill_routine() sequence); below is an example of such a sequence:

//aircraft selected

PANEL_SERVICE_CONNECT_TO_WINDOW
PANEL_SERVICE_PRE_INSTALL
PANEL_SERVICE_POST_INSTALL
PANEL_SERVICE_PRE_INITIALIZE
PANEL_SERVICE_POST_INITIALIZE
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
PANEL_SERVICE_PRE_GENERATE
PANEL_SERVICE_POST_GENERATE
---PANEL_SERVICE_PRE_DRAW
---PANEL_SERVICE_POST_DRAW
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
...//(_DRAW_, _UPDATE_ constantly repeated)
---PANEL_SERVICE_PRE_DRAW
---PANEL_SERVICE_POST_DRAW
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
PANEL_SERVICE_PRE_KILL
PANEL_SERVICE_POST_KILL

// window resize

PANEL_SERVICE_PRE_INSTALL
PANEL_SERVICE_POST_INSTALL
PANEL_SERVICE_PRE_INITIALIZE
PANEL_SERVICE_POST_INITIALIZE
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
PANEL_SERVICE_PRE_GENERATE
PANEL_SERVICE_POST_GENERATE
---PANEL_SERVICE_PRE_DRAW
---PANEL_SERVICE_POST_DRAW
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
...//(_DRAW_, _UPDATE_ constantly repeated)
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
---PANEL_SERVICE_PRE_UPDATE
---PANEL_SERVICE_POST_UPDATE
PANEL_SERVICE_PRE_KILL
PANEL_SERVICE_POST_KILL
PANEL_SERVICE_DISCONNECT

//aircraft change

This example shows that the gauge will run on every window resizing through a 'kill','install/initialize' sequence (just like in FS98). Unlike FS98, it is possible to distinguish an aircraft change from a window resize: with FS2000 there is PANEL_SERVICE_CONNECT_TO_WINDOW at startup and PANEL_SERVICE_DISCONNECT at shutdown.

Also the whole gauge is loaded at startup and released at a change to the next aircraft, which is not like FS98 where a gauge is reloaded on every window resize. The ..._UPDATE service_ids occur in a fixed cycle at 18Hz, the ..._DRAW service_ids are synchronous with the frame rate (sounds logical: why draw when no one can see it, but it didn't stop FS98 using the same fixed 18Hz cycle both for drawing and updating).