Up until a few compiler runs ago (few = haven't a clue how many) the panel I'm developing worked equally well in both FS9 and FSX. Now in FSX I get an outside view that is obviously part of a gauge bitmap and many other instruments appear to be loading bitmaps out of order. The top resource number is in the low 31Ks; I recall Bill saying something about 40K being the 'night' bitmap boundary. I'm not using standard bitmaps but using the trick of defining the panel background as part of a gauge, so the panel bitmaps are RGB 0,0,0.I'm using VS2003 and compiling a release version set to Multithreaded DLL. I tried setting it to /MT (as per Patrick's problem with Vista64) but that had no effect.I had this problem quite a while back and it 'went away', but this time it's resisting all the best efforts of my fairy godmother. And me.I'd ask if anyone would like to be my fairy godfather but on the grounds that it's sure to be misinterpreted, I'll settle for some ideas on how to deal with this problem.-Dai

Don't forget that there are TWO seperate "alternate schemes" to deal with with regards to resource numbering...In addition to the "new nighttime alternate" bitmaps we still have to mind the "high-low resolution" bitmap scheme as well!0x1000 lo-res bitmap0x1500 hi-res bitmapEven if we don't use hi/lo alternates, that means that if we use 0x1000, we can NOT use 0x1500 in the same gauge without conflicts... :(IOW, any #defined resource number + 500 is not available...

Hi BillThat has to be it. My debugger has resource #100 and comm1 background is resource #600; the debugger is showing comm1 as its background. Effectively then, out of 40K possible resource numbers you only (only!!!) have 20K that are usable and every 500, you need to jump 500 i.e. 0-499 then 1000-1499 etc. Must get that into sdXXgau fairly shortly.I inherited this s*dding project with a request to 'debug it because the original programmer has disappeared off the face of the earth'. Actually, I'd say that the original programmer had made such a cods of it that he couldn't be bothered to fix it - or didn't know where to start.-Dai

Hi Dai! Yep, that's the problem alright!I have a "sticky post" in my flightsim.com Panel & Gauges forum where I suggest a rational "scheme" for resource numbering that at least has the benefit of eliminating all possibilities of conflicts, and since there are precisly 9,500 resource id's available, that should satisfy even the most ambitions gauge programmer... ;) Please feel free to use any of what I've posted in your future updates...http://forums.flightsim.com/dc/dcboard.php...sg_id=732&page==============================================================One of the major shortcomings of the SDK is that absolutely no mention is made of the requirements for resource numbers, including the various auto-offsets that the panel system will look for...Further complicating the issue is that in FSX, a resource number offset precisely 40,000 (decimal) is used for auto-swapping a night version of the base resource number's bitmap.Some months ago, Jean-Luc suggested one possible scheme that at least has the virtue of being guaranteed "safe," since it takes into account all of the conditions placed by the panel system on resource numbers.I've since expanded the list to take advantage of the full dynamic range of allowable numbers. Below is the complete list of "Safe Ranges:"// 0x0100-0x02F3 0x0500-0x07F3 0x0900-0x0AF3// 0x1100-0x12F3 0x1500-0x16F3 0x1900-0x1AF3// 0x2100-0x22F3 0x2500-0x26F3 0x2900-0x2AF3// 0x3100-0x32F3 0x3500-0x36F3 0x3900-0x3AF3// 0x4100-0x42F3 0x4500-0x46F3 0x4900-0x4AF3// 0x5100-0x52F3 0x5500-0x56F3 0x5900-0x6AF3// 0x6100-0x62F3EDIT: New "FS Wiki Entry":http://www.fsdeveloper.com/wiki/index.php?...ource_Numbering

Hi BillThat did fix it - many hours and much wristache later. The publisher in question needed it fixed rapidly because he is intending to show the product at the Avsim conference. Mind you, he didn't tell me what he intended until the $h!t hit the fan on Monday night!Now to find out why I still can't get the alpha channel to work correctly on the ADI... new thread, maybe.-Dai