ELEMENT _HEADER* s - What's the diff?

[Guest HC001ST - Stick]

Is this:

PELEMENT_HEADER eng_oil_temp_needle_list[] ={	&eng_oil_temp_needle.header,	NULL};

equivelent to:

PELEMENT_HEADER eng_oil_temp_needle_list = &eng_oil_temp_needle.header;

in the sense that they could be used interchangably? I realise the array form would be used when there were non-overlapping sub-elements, but it seemed my gauge does not work with the 2nd form. Why?

[Guest _ak]

These forms not equivalent.1st form is array of elements and NULL is a end of array marker.FS handles every element in array until NULL not found

[Guest HC001ST - Stick]

Yeah, I realise that difference, what I'm not understanding is why when you have only one (1) element, it still requires the array form in the code.

[Guest bartels]

Internally FS uses always the array form. On runtime a copy of the whole image structure is dynamically made and then this copy is used, the original structure is only used as template. In FS2002 and earlier it was equal to use arrays or one ELEMENT_HEADER, in FS2004 it seems not. I always use the array form, so I propably haven't noticed yet.Being quite lazy I use the MAKE_PLIST macro to have the one-element-array in one go:#define MAKE_PLIST( name , next_header ) PELEMENT_HEADER name[] = { (PELEMENT_HEADER) (next_header) , NULL }; e.g.:...static MAKE_PLIST(plist_cover,NULL)static MAKE_STATIC( cover, BMP_COVER, &plist_cover,...static MAKE_PLIST(plist_needle,&cover)static MAKE_NEEDLE( needle, BMP_NEEDLE, &plist_needle,...static MAKE_PLIST(plist_background,&needle)static MAKE_STATIC( background, BMP_BACK, &plist_background,...static MAKE_PLIST(plist,&background)...GAUGE_HEADER_FS700( GAUGE_W, gauge_name, plist, mouse_rect, gauge_cb, 0, 0, 0 );Arne Bartels

[Guest HC001ST - Stick]

#define MAKE_PLIST( name , next_header ) PELEMENT_HEADER name[] = { (PELEMENT_HEADER) (next_header) , NULL };Excellent idea Arne. Also nice to know you can put it above the element. Seems the codes a bit clearer this way.Know of anything to read to better understand dll programming in general?Thanks

[Guest zip]

The pre-processor strikes again! I still think we'd be a lot better off without the pre-processor, because it just confuses the issue to no-end, and as usual, it's simple once you know how it works... Hopefully we'll move on to C# with FS2006 (ok, this is a longshot, but I like to think positive).I like to think of this as a linked list, because while it technically is an array, thinking in terms of a list makes it easier to understand. Because your gauge is a DLL, and attached dynamically at runtime through a set of callback entry points as the panel.cfg is processed, FS needs to "walk" the list (not just elements, but sub-gauges as well) so it knows what's in your gauge. If you look at the gauge header, same thing.As far as learning the process, I found the best thing to do is to try it out, and see what the effects are. The documentation is both poor and antiquated, that doesn't help. Post questions here, we'll try to answer if we know.

[Guest SRS-103]

Well, I am a beginner in gauge programming, but I a bit disagree with Arne. His code of course works correctly. I think the situation is the following. At first the code as it should be based on SDK:PELEMENT_HEADER plist = &background.header;GAUGE_HEADER_FS700( GAUGE_W, gauge_name, &plist, mouse_rect,gauge_cb, 0, 0, 0 );The same in Arne's code: MAKE_PLIST(plist,&background)GAUGE_HEADER_FS700( GAUGE_W, gauge_name, plist, mouse_rect,gauge_cb, 0, 0, 0 );Both should work. In the 1st case plist is type of PELEMENT_HEADER, but we pass its address, i.e. type PPELEMENT_HEADER. In Arne's case plist is of type PPELEMENT_HEADER already, in fact it is a pointer to a single element PELEMENT_HEADER array (the array being terminated with NULL).This is not at all indifferent, but it seems for each gauge FS starts processing a single element and will NOT look for a second value. This is not logical, but if this would not be the case the SDK example would not work (it would crash, when FS would look for the next element in the list).This is the first element within the gauge which will be processed by FS. This is the root of a tree. This element is generally a background image created by MAKE_STATIC:MAKE_STATIC( background, BMP_COVER, pplistcover, ... )Here parameter 3 is of type PPELEMENT_HEADER, i.e. it is a pointer to a PELEMENT_HEADER, or pointer to a PELEMENT_HEADER array. FS interprets this in the second way and will process the PELEMENT_HEADER list until a NULL is found. That is why we have to define this parameter as an array (of pointers) even if it is a single item only.I am just guessing now, but I have the feeling that FS can start separate threads and process all the elements in this array parallel. This is why they recommend that define elements in this array only if they can be processed parallel, i.e. they are not overlapping.If they ARE overlapping, then you have to link them after each other, meaning only the very next element in this list only in the current list.It would be good to know which is the preferred way. One can use always the "single-threaded" approach (only one element in each list), but this might not be optimal. The other approach would be to collect all non-overlapping elements in a single array and let FS to process them parallel. Overlapping components can still be linked lineary resulting a mixed, but possible more optimal solution.Arne's solution is safer then the SDK example, because it would even work if they modify FS to start processing the gauge elements parallel from the root. It seems presently FS looks for a single element (the background) at first and starts multithreaded from there only. This is logical however, as it would not be good to process anything before the background is processed.Gabor Hrasko

[Guest darrenecm]

I see these posts are 2004 but having only just discovered this forum full of gauge programming wisdom I felt compelled to respond to Etienne's observation on this whole pre-processor business.Having only just got to grips with C I'm finding having to learn how things work in programming gauges using the SDK quite tiresome. Having to walk through all those macros to get a through understanding on what's going on behind the scenes is time consuming and confusing.My idea of an SDK is a documented listing of functions and data structures in plain C or C++ that educates you as to how to communicate with the target software. Once you have a clear understanding on how everything is constructed it's then that you should be presented with information on using macros to make things quicker to type in. An SDK should not take the form of an entire psuedo preprocessor language from the start.As it stands, newcomers are having to wade through all these convoluted macros to figure out what C code is being produced. This is acting as a barrier to my clear understanding of how things work at the moment. I think I'd learn far quicker if I didn't have to first 'unwind' all these macros. I've had a much easier time figuring out the entire DirectX SDK than I'm having with the FS2004 SDK at the moment :)

[Rocky 128]

I understand this, and I did the same macro as Arne did...I just regret that we can't put several gauge headers in each array of elements. I know that managing the gauge elements like this is very important for drawing priorities, but I would like to organize my gauge into "layers", each layer being composed of several gauge elements referenced in an array.Something like:...PELEMENT_HEADER layer1_list[] = {&element1.header,&element2.header,&element3.header,NULL};...PELEMENT_HEADER layer2_list[] = {&element4.header,&element5.header,&element6.header,NULL};I tried this, and it appears it doesn't work...Eric