I created a MAKE_ICON callback like this:ICON_UPDATE_CALLBACK icon_cb;Added the callback to the MAKE_ICON macro:MAKE_ICON( ... GENERAL_ENGINE1_FAILURE, icon_cb, // Sourc_var, callback ...)and defined the function like this:FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement_icon){ // TODO Add stuff here}and all compiles with not even a warning. However, when I run FS9 with this gauge, it crashes when loading the panel.Without the above callback, there is no crash and everything works fine.Any idea what I am doing wrong?Patrick

Actually, it seems to be a combination of things. First, here's a typical example of the macro fields:MAKE_ICON( fuel_selector_icon, BMP_FUEL_SELECTOR_OFF, NULL, NULL, IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY, 0, 0,0, FUEL_TANK_SELECTOR,fuel_selector_icon_cb, ICON_SWITCH_TYPE_STEP_TO, 4, 0, 0)Note carefully that the "Switch Type" is declared as ICON_SWITCH_TYPE_STEP_TO. This is the most common method this macro is used. Note that the number of icon elements is 4.In the .h file, the resource id's in each #define for icon bitmaps is sequential, i.e.#define BMP_ICON_1 0x1000#define BMP_ICON_2 0x1001#define BMP_ICON_3 0x1002#define BMP_ICON_4 0x1003Now, take note that the variable used for "icon switching" needs to be set such that the default value will be 0 (zero), and that the variable will increment in steps of 1 (one), i.e., a range of 0 - 3...For a three position flap lever, I might use this formula to generate the values I need for a three bitmap ICON element:flap_setting = FLAPS_HANDLE_POSvar.var_value.n/8192; //max val 16384In your example, since you are presumably passing a boolean variable, your callback should be like this:FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement){ FLOAT64 val=pelement->source_var.var_value.b; return val;}

Bill,Found the problem.This code:FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement){ // TODO Put stuff here.}compiled fine, but the lack of a return is what caused the problem. When I changed it to:FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement){ FLOAT64 val=pelement->source_var.var_value.b; return val;}worked like a champ. I suspect that the implicit return, returned random data, and that this played havoc with something.Thanks, your post gave me the idea.Patrick

>Bill,>>Found the problem.>>This code:>>FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement)>{> // TODO Put stuff here.>}>>compiled fine, but the lack of a return is what caused the>problem. When I changed it to:>>FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement)>{> FLOAT64 val=pelement->source_var.var_value.b;> return val;>}>>worked like a champ. I suspect that the implicit return,>returned random data, and that this played havoc with>something.>>Thanks, your post gave me the idea.>>Patrick>This line... FLOAT64 val=pelement->source_var.var_value.b;...is living dangerously.

Yes, I realized after exploring more that I wasn't forced to implicitly cast.Should have been:FLOAT64 FSAPI icon_cb(PELEMENT_ICON pelement){ return pelement->source_var.var_value.n;}Now that I understand that the MODULE_VAR I was attempting to use was a number, not a bool.So, hope that helps you.

>This line...>> FLOAT64 val=pelement->source_var.var_value.b;>>...is living dangerously.Not is the variable being passed is boolean (as I mentioned)...Using the right member is *sometimes* critical:.b.n.eMostly, this will eliminate those pesky "warnings" from the compiler, but using .e is truly required in those cases where the variable type is "environment"... ;)

Thought .e is 'enumerated'?Yes, I wasn't so worried earlier mainly because they all return a FLOAT64 (aka double), and come from a unionized universal var. But as a management guy, I'm a little leary of unions, haha.Patrick

Yes, enumerated... (where did "environment" come from?) Note to self: check meds dosage more carefully... ;)