Well, this has been an interesting few weeks...I have a large "multi-gauge" project that has been throughly tested in both FS9 and FSX running under WinXP and Vista, and works correctly. It also works well in FSX running under Win7 x64.However, it has been FAILING in FS9 running under Win7 x64 consistently. Any popup window that was moved would not be cleared and redrawn, but simply tiled over and over on screen. Worse, this locked FS9 so it simply quit running with no way to recover...Obviously, this has been of major concern!Running a Debug session didn't turn up any problems that I could find.Today, I tried a different approach and ran a Debug session on my development machine by loading the project in FS9 running under Vista and took careful note of the Output window.After the a/c had finished loading, I noticed a very long series of messages in the Output window about "integer division by 0" being generated by the multi-gauge in the FS9 process. When I looked for the offending code, I saw this line being marked in the "logic" section of PANEL_SERVICE_PRE_UPDATE:

gpstime = gpstemp  /  ( speed  /  60 ) ;

When I checked back, sure enough if the a/c isn't moving, "speed" will indeed be zero! Since this calculation only need be run whenever the a/c is moving, I simply added a condition to eliminate the "division by zero" issue:

	if (speed > 0)	     { gpstime = gpstemp  /  ( speed  /  60 ) ; }	else { gpstime = 0 ; }

When I recompiled the project and copied the .gau to my FS9/Win7 machine, the problem was solved! Hooray!The lesson learned was that Win7 is simply far less tolerant of "integer division by 0" than either WinXP or Vista, so if you run into a similar problem, check your code! :LMAO:NOTA BENE: I have no idea if the same problem might occur with an XML scripted "gauge," but it is something to consider should a similar problem crop up!

Nice find Bill!

That is interesting. I'd assumed that integer division always throws an exception. But, as you pointed out, it doesn't for FSX and XP - even though it does in a normal XP .exe application.Did you note what value was returned in the gauge?

That is interesting. I'd assumed that integer division always throws an exception. But, as you pointed out, it doesn't for FSX and XP - even though it does in a normal XP .exe application.Did you note what value was returned in the gauge?

WinXP FS9 and FSX - no problems notedVista x32 FS9 and FSX - no problems notedWin7 x64 FSX - no problems notedWin7 x64 FS9 - execution of sim's graphics drawing halted, but did not affect the GUI's operation.I didn't actually display the return in the gauge, so I can't really tell you what it may have been.At a guess though, I suspect that MS/ACES may have deliberately coded the sim to somehow trap division by zero and supress the exception......to take sloppy/lazy/inept "sim programmer's" practices into account. :(

Hey Bill,We've had an Integer Divide By Zero trap wrapped around most of the code in Flight Sim since at least FS4 (probably even earlier, that's just the earliest source I've had access to :-> ). Much easier/faster than running through all the conditional checking that would be required to avoid divide by zeros. The FS handler just returns a result of zero and clears the exception.Not sure what's up with FS9 on Win7, sounds like the trap wasn't working for some reason.Tim

What happens with floating point division by zero, does FS trap that exception too?

Much easier/faster than running through all the conditional checking that would be required to avoid divide by zeros. The FS handler just returns a result of zero and clears the exception.Not sure what's up with FS9 on Win7, sounds like the trap wasn't working for some reason.

Thanks for the information, Tim. I only stumbled onto this particular "gottcha" this one time, and it took me awhile to find the precise cause. I even tried launching FS9 on the Win7 machine using WinXP compatibility mode. Obviously there's something fundamentally different about Win7 that's ignoring FS9's handler, or at least its attempt to trap the exception...Normally I take special care to avoid this type of situation, but in this case I "inherited" the original source code consisting of around 80 separate gauges, and had to do a lot of work to convert 'em into a single multi-gauge.Thankfully, this is the last time I'll have to go through this process! Converting nearly 200 shared pointer variables was a nightmare I'd just as soon endure again! :(