Can anyone please give me an example in C of how to use this macro? I've obviously completely misunderstood its use as I can't get it (or its related macros) to work and apart from using it myself, I'd like to include the info in the next issue of sd2gau.-Dai

Hi Dai,I've followed your other thread. Obviously, it is supposed to tell the panel system to redraw the gauge on the screen.I remember having run through the same issues (i.e. the gauge not re-displaying) and I think this happens when you SET_OFF_SCREEN in an element callback.I exclusively use SET_OFF_SCREEN in the PRE_DRAW event (the plase it should fit best), that is at the time right before FS draws the gauge.something like:case PANEL_SERVICE_PRE_DRAW:adf_gauge_glcontext.hImg = (PELEMENT_STATIC_IMAGE) get_listelement_pointer(pgauge->elements_list[0],adf_TDXP_SURFACE);[...]SET_OFF_SCREEN(adf_gauge_glcontext.hImg);break;Hope this helps!

Dai,I used a block of code like this:LUMINOUS_IMAGE(pgauge->elements_list[0]);LUMINOUS_IMAGE(pgauge->elements_list[0]->next_element[0]);LUMINOUS_IMAGE(pgauge->elements_list[0]->next_element[0]->next_element[0]);REDRAW_IMAGE( pgauge->elements_list[0] );It's in a function which is itself called from a needle macro callback function.I'll send you the complete source code, as I think it will represent one approach to what you are trying to get at here.Doug

Hmmm... suppose you only wanted to apply LUMINOUS to the 4th element in the list, and BRIGHT to the 5th element in the list???

>Hmmm... suppose you only wanted to apply LUMINOUS to the 4th>element in the list, and BRIGHT to the 5th element in the>list???LUMINOUS_IMAGE(pgauge->elements_list<0>->next_element<0>->next_element<0>->next_element<0>);LIGHT_IMAGE(pgauge->elements_list<0>->next_element<0>->next_element<0>->next_element<0>->next_element<0>);REDRAW_IMAGE( pgauge->elements_list<0> );Haven't tried that, but can't see why it wouldn't work...Doug

Just FYI ATM, because I haven't done much more real research; the really, really dirty way to ensure that any image flag is applied when required is to ensure that every single macro has an active callback. You've probably spotted the catch; if the macro is a static icon it means that you need to list the same icon bitmap twice in the .rc file and give it two numbers in the resource header file. The end result is to make the macro callback swap two identical images each time you change the image flags. It works, perfectly (mixed flags and all, Bill)..... but IIRC, the compiler is stupid enough to package up the same bitmap twice. -Dai

A somewhat different approach to be sure, but I'm successfully using this technique that will ensure that you only have to have one resource and one bitmap...Duplicate the MACRO twice and make necessary edits to the copies to make 'em unique and so they'll "chain" properly...Duplicate the original callback and make the needed edits to match the MACROs...Now using the same bitmap resource I can have "OFF", "LUMINOUS" and "BRIGHT" conditions......or, with the addition of only one more bitmap resource, I can have "OFF", LUMINOUS (dim1), LUMINOUS (dim2), BRIGHT (bright1), or BRIGHT (bright2).Wheee! This is fun! ;)BTW, the main reason why I'm doing it this way is so that I can treat each gauge element differently if necessary...

Dai, I'm almost sure that if you do it in the main gauge callback (PRE_DRAW) it works as advertised, for anything (static, icon etc...)

Bill: Now that technique is a Blast From The Past! I feel like kicking myself for overlooking the really simple way of doing it... grrrr :)JeanLuc: I will definately give it a try, thank you.-Dai

Hi DougThat list of next_element(s) made me shudder :). Have a couple of tested working freebies:-#define LUMINOUS_LISTELEMENT(pelement,pos_element) add_imagedata_to_listelement(pelement,pos_element,IMAGE_USE_LUMINOUS )#define DELUMINOUS_LISTELEMENT(pelement,pos_element) remove_imagedata_from_listelement(pelement,pos_element,IMAGE_USE_LUMINOUS )Place them down with HIDE_LISTELEMENT in your gauges.h file and use in he same way. While we're at it, anyone want to try these? Same place, same syle but I've just run them up without testing.#define SET_OFFSCREEN_LISTELEMENT(pelement,pos_element) add_imagedata_to_listelement(pelement,pos_element,IMAGE_ON_SCREEN)#define SET_ONSCREEN_LISTELEMENT(pelement,pos_element) remove_imagedata_to_listelement(pelement,pos_element,IMAGE_ON_SCREEN)Watch out for the wrapround. I'll be adding these to the fs9gauges.h in the next release of sd2gau; anyone want to add anything of their own?-Dai

>Just FYI ATM, because I haven't done much more real research;>the really, really dirty way to ensure that any image flag is>applied when required is to ensure that every single macro has>an active callback. You've probably spotted the catch; if the>macro is a static icon it means that you need to list the same>icon bitmap twice in the .rc file and give it two numbers in>the resource header file. The end result is to make the macro>callback swap two identical images each time you change the>image flags. It works, perfectly (mixed flags and all,>Bill)..... but IIRC, the compiler is stupid enough to package>up the same bitmap twice. Dai,Planning a design helps. Generally, I look at each to see how I need to divide up a gauge into elements to allow the appropriate flags to apply to only the parts of interest.For example, a typical gauge has a static case, a static face that may require luminous or bright tags, and the moving needle. Now with alpha I could make the case and face a part of the same image if I so choose. Thus, any element can have whatever tags set that I need.I do not follow your assumption that if an image is static it means duplicating a bitmap. If you design your bitmaps appropriately there is no need. Also, you can easily use the same resource more than once without duplication by simply refering to the appropriate ID. Have it in the .rc file once, and in the .h you can have multiple names for it without problem.Yes, you could instruct the compiler to put two versions of it in your .dll, but I would argue that it is not the compiler that would be stupid in this case.

Hi PatrickUnfortunately I don't have the luxury of planning this particular panel; I've been asked to debug a commercial project and I have to work with what I've been given on a far-too-tight timescale because the original programmer let the publisher down badly. I'm well and truly jammed into the 'if it works consistently and it doesn't affect the framerate, use it' position.I agree wholeheartedly though; planning is the only way to get good, clean results.Oh, and I agree with your argument about the 'stupid compiler'! I had to 'come out of retirement' for this project and I've forgotten far too much. Thanks for the reminder about just using the resource file.-Dai