... except that now I don't believe FS9 for one moment. Actually, the title should read 'Your computer has run out of available memory', followed by 'Flight Simulator will now exit'. Initially I thought it might be telling the truth because I have been using large bitmaps for the current panel, so I went back and reduced many of them in size until the final gauge was 40Mb smaller than previously. That didn't fix it so I commented out a lot of gauges, to absolutely no effect. I tracked the trouble down to one gauge - the weather radar display - and then made the assumption that perhaps I'd inadvertently introduced an infinite loop into the code. That too proved to be a dead-end as commenting out all the update code still produced the same error message. This aircraft has a WR display on both sides and the (eye candy) display data is generated by the captain's display, then used by both. In theory, if I loaded the captain's display on the FO's side as well, then FS should crash good and proper because I'd have two identical gauges fighting over the same data. Only, it didn't. So what I'm asking is, has anyone else hit this error message and what sort of solution did they find? I don't expect an answer to my problem, just some possible leads for me to follow up. It's all written in good old C code Thank you. -Dai

Dai, Happens sometimes after 15 minutes, sometimes after more than 6 hours.In the mean time no changes made in airceaft and/or panel.So no clue.Cannot prove, but a lot of "RELOAD" when editing something seems to aggravate the thing. Jan

Hi Jan 'Post it and find it' - isn't that always the way? I took the 'nuke it' approach just after posting and started recreating the gauge by initially copying the code for the captain's side (because I knew this worked on both sides) and intending to change it step-by-step to become the FO's side again. So, the first step was to replace all instances of 'wr_capt_xxxx' in the code with 'wr_fo_xxxx' as this would define the variables as being specifically for the FO's radar. Compile it, load it and run it - no problem. Next move, do the same to rename the bitmaps from 'WR_CAPT_XXXX' to 'WR_FO_XXXX' in the macros as this would call in the FO side-specific bitmaps (different shading etc.). Compile, load it, crash. Eh? What? Start by re-renaming the bitmap calls in each macro one-by-one back to 'WR_CAPT_XXXX' until it stops crashing. Success on the first attempt! At this point I've narrowed it down to three possible bitmaps, all part of the same icon stack. Check bitmap sizes - hello; one's slightly bigger than the other two even though all three have the same dimensions. Open up Photoshop to check more closely, run 'Save As' across the errant bitmap - and find that I've saved it as a 24-bit OS/2 bitmap..... It wasn't me, honest. My mouse does magic tricks with the save dialog when I'm not looking. I didn't do it..... So, I loaded the original .psd file, saved it as a bitmap into the correct Windows format and of course, it all works properly now. Many thanks for the reply. Maybe this salutary tale will help someone else. -Dai

Dai, I feel your pain. It's always annoying to track down problems because it just kills one's productive 'mojo.' Invariably, whenever I build up a good head of steam and am streaking through my 'to do list,' I'll run across a problem that stops me dead in my tracks... ...after which, after having finally found and solved the proximate cause of the problem, it takes me a l-o-n-g time to reboot my creative juices. <sigh>