Now that I finally managed to get the Borland BCC55 environment set up,I'm able to code in pure C and compile gauges (including multi-gauges) using the SDK.c etc. files.What I *haven't* sorted out yet though, is how to get the following code tocompile properly. The Borland compiler throws up on it! :(+++++++++++++++++++++++++++++++++++++++++char esdg_cabin_lights_gauge_name[] = GAUGE_NAME;extern PELEMENT_HEADER esdg_cabin_lights_list;PELEMENT_STATIC_IMAGE bg_element =NULL;extern MOUSERECT esdg_cabin_lights_mouse_rect[];GAUGE_CALLBACK gaugecall;GAUGE_HEADER_FS700(GAUGE_W, esdg_cabin_lights_gauge_name, &esdg_cabin_lights_list, esdg_cabin_lights_mouse_rect, gaugecall, 0, 0, 0);#define GAUGE_CHARSET2 DEFAULT_CHARSET#define GAUGE_FONT_DEFAULT2 "Courier New"#define GAUGE_WEIGHT_DEFAULT2 FW_THINint FIRST_RUN=0;int cabinlights;void FSAPI gaugecall(PGAUGEHDR pgauge, int service_id, UINT32 extra_data){switch(service_id){case PANEL_SERVICE_PRE_INITIALIZE:bg_element = (PELEMENT_STATIC_IMAGE)pgauge->elements_list[0];break;case PANEL_SERVICE_PRE_DRAW:if (FIRST_RUN==0) {FIRST_RUN=1;cabinlights = 0 ; }break;case PANEL_SERVICE_PRE_INSTALL:break;}}BOOL FSAPI mouse_cb0( PPIXPOINT relative_point, FLAGS32 mouse_flags){trigger_key_event (KEY_TOGGLE_CABIN_LIGHTS,0) ; if ( cabinlights == 0 ) { cabinlights = 1 ; } else { cabinlights = 0 ; } return FALSE;}MOUSE_TOOLTIP_ARGS (GPS_Args)MOUSE_TOOLTIP_ARGS_ENDMOUSE_BEGIN(esdg_cabin_lights_mouse_rect,0,0,0)MOUSE_CHILD_FUNCT(3,1,25,62,CURSOR_UPARROW,MOUSE_LEFTSINGLE,mouse_cb0)MOUSE_ENDFAILURE_RECORD fail2[] = {{FAIL_NONE, FAIL_ACTION_NONE}};FAILURE_RECORD fail1[] = {{FAIL_NONE, FAIL_ACTION_NONE}};FLOAT64 FSAPI callback2( PELEMENT_ICON pelement){FLOAT64 rwert=pelement->source_var.var_value.n;rwert = (float)cabinlights ; return rwert;}MAKE_ICON(Icon2,Rec1,NULL,fail2,IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY | BIT7,0,2,8,MODULE_VAR_NONE,callback2,ICON_SWITCH_TYPE_STEP_TO,2,0,0)PELEMENT_HEADER ElementList2[] = {&Icon2.header,NULL};MAKE_STATIC(Static1,Rec0,&ElementList2,fail1,IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY | BIT7,0,0,0)PELEMENT_HEADER esdg_cabin_lights_list = &Static1.header;+++++++++++++++++++++++++++++++++++++++++++++++Even very simple code that compiles perfectly in MinGW causes Borland tochoke up with these errors!MAKE Version 5.2 Copyright © 1987, 2000 Borland bcc32 -O2 -w-par -q -6 -Oc -OS -Ov -tWD -DWINVER=0x0400-D_WIN32_WINNT=0x0400 -Oi -RT- -v- -x- -xf -P- -Tkh32768 -c esdg_citII.cMAKE Version 5.2 Copyright © 1987, 2000 Borland bcc32 -O2 -w-par -q -6 -Oc -OS -Ov -tWD -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -Oi -RT- -v- -x- -xf -P- -Tkh32768 -c esdg_citII.cesdg_citII.c:Error E2293 esdg_citII.cabinlights.c 6: ) expectedError E2264 esdg_citII.cabinlights.c 37: Expression expectedError E2451 esdg_citII.cabinlights.c 57: Undefined symbol 'gaugehdr_cabinlights'Error E2040 esdg_citII.cabinlights.c 57: Declaration terminated incorrectlyError E2190 esdg_citII.cabinlights.c 57: Unexpected }Error E2190 esdg_citII.cabinlights.c 57: Unexpected }*** 6 errors in Compile ***** error 1 ** deleting esdg_citII.obj+++++++++++++++++++++++++++++++++++++++++I've checked line #6 throughly, and there's a bloody ")" exactly where its supposed to be...

just a wild guess:GAUGE_HEADER_FS800(instead ofGAUGE_HEADER_FS700(Hope this helps!

>just a wild guess:>>GAUGE_HEADER_FS800(>>instead of>>GAUGE_HEADER_FS700(>>Hope this helps!Well, it cleared all errors except this one!++++++++++++++++++++++++++++++++++MAKE Version 5.2 Copyright © 1987, 2000 Borland bcc32 -O2 -w-par -q -6 -Oc -OS -Ov -tWD -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -Oi -RT- -v- -x- -xf -P- -Tkh32768 -c esdg_citII.cesdg_citII.c:Error E2264 esdg_citII.cabinlights.c 37: Expression expected*** 1 errors in Compile ***** error 1 ** deleting esdg_citII.obj++++++++++++++++++++++++++++++++++When I comment out lines #36 and #37, the gauge compiles...//MOUSE_TOOLTIP_ARGS (GPS_Args)//MOUSE_TOOLTIP_ARGS_END

Maybe it does not like an empty array and complains about it?!Besides, just a tip I'm often using to avoid having a CPU stalling with miss branch predictions....if ( cabinlights == 0 ) { cabinlights = 1 ; } else { cabinlights = 0 ; }is safely replaced, and P4/Athlon better, by:cabinlights = 1 - cabinlights;!!!

>Maybe it does not like an empty array and complains about>it?!Probably... It works just fine without it! I've no idea why Easy Gauge creates that "array" anyway, but the MinGW compiler doesn't seem to care one way or another... >Besides, just a tip I'm often using to avoid having a CPU>stalling with miss branch predictions....>>if ( cabinlights == 0 ) { cabinlights = 1 ; } else {>cabinlights = 0 ; }>>is safely replaced, and P4/Athlon better, by:>>cabinlights = 1 - cabinlights;Hmmm... that's a lot less "typing" too! :)Of course, my ultimate "goal" is to take a whole bunch of small gauges and combine 'em into one multi-gauge. Thanks to your able assistance, I'm close to achieving my goal!One other anomaly I found was hiding in the .h file:EG produces...#define Rec0 0x100 :)

Bill,What MingGW version are you using. I seem to only be able to use the 2.95.2 version. The later versions I tried seem to not work with the make files provided by Dai Griffiths and Arne Bartels in sd2gau15.zip.W. Sieffert

>>cabinlights = 1 - cabinlights;>cabinlights = !cabinlights;:)

>Bill,>>What MingGW version are you using. I seem to only be able to>use the 2.95.2 version. The later versions I tried seem to>not work with the make files provided by Dai Griffiths and>Arne Bartels in sd2gau15.zip.MinGW - Minimalist GNU for Win32Version 2.0.0http://www.mingw.orgMinGW version 2.0.0 contains the following list of packages:GCC-3.2-core-20020817-1binutils-2.13-20020903-1mingw-runtime-2.2w32api-2.0gdb-5.1.1-1make-3.79.1-20010722 (binary renamed as mingw32-make)I tend not to "upgrade" stuff that's working well as it! :)

tested with BorlandC and seen in VC++ compiled code:var = !var; does not produces pairable UV instructions in all cases (context dependant)var = 1 - var; does better from my experience.Also, binding an int to test a TRUE/FALSE condition is compiler dependant, and language dependant (differences between C and C++, for which there is a real boolean type). This means that you know it is TRUE or FALSE, but you can't ensure the value of the int.In most cases, !var; with var as an int may produce a sequence of 0 and -1. If the int value is also used to index an array for example, from which you get a value (bitmap, whatever...) then it becomes useless. var = 1 - var; ensures the values are the ones you want.I may be completely wrong though.:-)

Here's a new puzzle!I have a very simple "Audiopanel" gauge that works 100%, but for some reason FS Panel Studio will choke on with a nasty error (occasionally causing complete computer lockup!).What is odd is that it was working in FSPS, but after changing the "click sounds" and recompiling, FSPS will crash... adding to the mystery is that FS2k2 and FS9 have no issues with this gauge, but will happily run with it installed.This same thing has suddenly occurred with my EHSI (which is extremely complex); one day FSPS would load/display it perfectly, after a recompile to change/add a few elements, FSPS is choking on it. As with the "Audiopanel" gauge, all versions of FS have no problems with it.Just for the sake of building experience and skills, I recompiled the "Audiopanel" gauge with the BCC55 compiler; FSPS still chokes on the gauge, but FS is happy!On another note, the MinGW compiler seems able to compile "tighter" than the BCC55 compiler. There is a huge difference in file size of the .gau files:MinGW = 187 KBBCC55 = 223 KBIs the difference in sizes related to the extra header info needed (I compiled in BCC55 as a multi-gauge)?

The size difference is possibly due to different "optimization" settings, mainly inserting or letting out quite big chunks of zero data in the end result. Any extra header info will only add marginally to the gauges size (some Kbs maybe, presumably only a hand full bytes). In my experience the CFGedit choked on gauges that had some extra dll linkage in them, e.g. sound dlls, FSPS might do the same. You can ignore it or try to find the right dll in the FS modules folder and copy it to the FSPS program directory (or directly in windowssystem).Arne Bartels

>The size difference is possibly due to different>"optimization" settings, mainly inserting or letting out quite>big chunks of zero data in the end result. Any extra header>info will only add marginally to the gauges size (some Kbs>maybe, presumably only a hand full bytes).That's likely what is happening then.>In my experience the CFGedit choked on gauges that had some>extra dll linkage in them, e.g. sound dlls, FSPS might do the>same. You can ignore it or try to find the right dll in the FS>modules folder and copy it to the FSPS program directory (or>directly in windowssystem).Arne, what is truly puzzling is that FSPS was loading/displaying the "Audiopanel" gauge perfectly!The only change made was the name of the .wav file from "click.wav" to "push.wav..."The same is true of the EHSI. Other gauges that were modified to use "push.wav" still load/display in FSPS, so the .wav name is a "red herring," and cannot account for the anomaly, and they also use the same GaugeSound.dll for sound.Ah well, as a "workaround" I've simply placed a "dummy .gau" in the gauges folder which only has a background bitmap for gauge placement purposes; the "real" .gau is in the a/c's panel folder for developmental purposes! :)I've encountered this problem with FSPS in the past with other people's gauges, and had worked with the author of FSPS to "fix" the problem. I'll have to contact him again to see if there's a new "fix" available... :)