Hi everyone,I have created some of my own class objects and delcared them with the "new" key-word. The problem is that I cannot figure out when to "delete" them. I have done this is the PANEL_DISCONNECT but it causes a FS9 to crash upon switching aircraft and subsiquently not to load. Any ideas?ThanksJon

It should work if you initialize your class object in PANEL_SERVICE_CONNECT_TO_WINDOW and delete it in PANEL_SERVICE_DISCONNECT. Everything between these two events might be called multiple times. EDIT: in some cases CONNECT_TO_WINDOW is called multiple times in FS9 too. You might want to put some code into your gauge, which checks if the code in CONNECT_TO_WINDOW has already been executed or not.

Do you know when the multiple PANEL_SERVICE_CONNECT_TO_WINDOW occure? In my tests I get always a frame of PANEL_SERVICE_CONNECT_TO_WINDOW...PANEL_SERVICE_DISCONNECT as the very first and the very last service_id of a gauge in a panel without reloading the plane.It is of course different if the same gauge is used more then once in a plane, so it "looks" as if there where double PANEL_SERVICE_CONNECT_TO_WINDOWS events, but they are the both events of the both "incarnations" of the same gauge. In these cases the nice mechanism that all gloabls are available to all gauges of a multigauge (including incarnations of the same subgauge) bites back: if you have to get an object with "new" that is unique to the gauge appearance, you can't store the pointer in a global variable, because it would be the same for both gauge appearances. To get variables that are definetely unique to the gauge incarnation, you can use some of the free GAUGEHDR variables, like pgauge->usage or redefine the pgauge->user_area[] from FLOAT64 to UNIVERSAL_VAR, which have the same size and gives an array of 10 user variables (the 10*64 bit block could also be PVOID user_area[20], or suchlike, I prefer UNIERSAL_VAR, "only" ten free vars, but those flexible).Arne Bartels

Looks like we have to wait for the sdk then! If we knew how many times the Disconnect was called before the plane is actually deselected then I can overcome this problem. However, I don't think that we can predict it because the if the plane is in the default flight, the calls will be made even if the user selects another flight which explains why my FS9 kept crashing before (nothing to do with GDI+). I would try Arne's solution except Im not quite sure how it works and I have quite a few class objects to declare. Since Im making the whole panel, I can be sure that there won't be two of the same gauge. Ive just main one gauge entitled "the_brain" that handles all my systems work ;-) So has anyone found another way around this?

you can write own module_init and module_deinit functionsOriginally they empty but you can write some code there :)They called only once when gauge just loaded and just before unloading

Hi,every gauge callback event is framed between a connect/disconnect pair. This occur for each instance of the gauge loaded in memory (say you have 2 of the same gauge on the same panel, like mygauge!gau1 and mygauge!gau1 again elsewhere on the panel).the thing is that when selecting an aircraft in the create a flight window, the gauges are not only loaded, but the connect event is sent too. When you press OK to load the flight, then it calls for a disconnect, then reloads the gauges again and call for a connect...this is new in FS2004 :-(Following Arnes advice, you could allocate heap memory in the connect event and store the pointer in the user data area. Then, when you new your class, you store the pointer of the class instance in the memory you allocated in the heap! This way, you can have as much memory as you need!The module_init functions are nice because they are actually the DLL connect / disconnect events (a GAU is a DLL). I never used them, and I wonder if when the DLL connect event occurs, do you have access to FS SDL event (trigger_key, init_var, lookup_var etc....)?! They may be not initialized yet and available to the gauge at this early loading time in FS?!

>>The module_init functions are nice because they are actually>the DLL connect / disconnect events (a GAU is a DLL). I never>used them, and I wonder if when the DLL connect event occurs,>do you have access to FS SDL event (trigger_key, init_var,>lookup_var etc....)?! They may be not initialized yet and>available to the gauge at this early loading time in FS?!>You will have access to them, no problem there