Thanks for the info Doug. I just saw this post. I almost missed it wading through all of this mess. Talk abouta flippin hijack. sheeeeesh

I hope the article there is helpful. I tried to make it as complete as possible, yet simple enough to understand! :(

Some code I received recently from an extremely helpful commercial developer on this forum shows that he is using the hdc of a STATIC_ELEMENT as a drawing surface. This is also the method displayed by Microsoft in their ESP sample ESPDrawing GaugesUsingGDI+.zip found here. As I am reluctant to pass on such code without permission, you could try asking Bill for his GDI template. It may be possible to use the hbmp but I haven't tried it.-Dai

Greetings Dai.That ties in with what I remember experimenting with when trying to get OpenGL 'boilerplate' setup code to accept a suitable render target and surface format. I distinctly remember becoming irritated that I appeared stuck with a DIBSECTION in system memory and unable to specifiy a surface in video memory as I had been doing with general OpenGL applications while learning C++ :)In wading through the gauges.h using the useful object and class browsing tools within Visual Studio, I just encountered other numerous declarations of bitmaps here and there, as well as image buffer pointers, and I don't seem to have found any discussion of whether they are useful, or even if we should steer well clear of using them for simulation stability concerns. I was madly trying to find a way to coax FSX cooperating with my need to use video memory, but it appeared hopeless :( Bill kindly passed his GDI+ template to me during my brief chats with Ron and others on the Eaglesoft team two or three years ago. Stasi of Mindstar G1000 fame was also generous with his knowledge (he sure knows his C++). Ever on the lookout for improving the Eaglesoft product lineup, Ron seemed interested in assessing whether OpenGL could prove to be a suitable alternative to GDI+ regarding overall performance. I'm not entirely sure but I don't think anybody had tried working with OpenGL at the time, or if they had they weren't telling. I just wish I'd had the time to develop faster as a C++ programmer and been more experienced with FS2004 gauge programming in general to be of more effective help to them. Sadly, that pesky bug-bear of real life and day job issues reared it's head and I was forced to move on.To be honest I'm surprised at this stage of the game, with the seemingly more open attitude of the FSX developers with their blogs and releases of ESP examples, that there's not been any detailed discussion on the topic of how FSX and gauge DLLs actually interact at a fundamental level, if only for the sake of establishing good programming practices for everyone, including pitfalls to avoid when creating non XML or bitmap sliding gauges. At least I haven't found any such discussions - any links would be welcome.As far as APIs go I have to confess that the Flight Simulator SDK regarding C gauges still remains fairly poorly documented and discussed when compared to the rest of the excellent SDK content. I guess this is what fuels the ever present rumours that C gauges are being phased out as too much hassle to support for much longer. The release of the GDI+ example was a hopeful step in the right direction though, so maybe there'll be more detailed discussions of the FSX panel and gauges systems to come as ESP gathers momentum? I certainly hope so.Well I've just finished reinstalling Visual Studio 8 on a clean system whose sole use is for software development. Time to start dabbling. After being coddled in the awesomely managed world of C# and it's rather excellent syntax and structure, getting back to the nuts & bolts DIY memory management of C++ should prove interesting. Especially with all the new bells & whistles of the Visual Studio environment and C++ language enhancements...so much to learn, so little time :(

And now you're asking about what the commercial developers do. :(

In the absence of being physically in your presence in order to use copious amounts of alcohol to glean more information Ed, one can only ask :(

There isn't enough alcohol... I don't drink. :(

Hi Darren

In wading through the gauges.h using the useful object and class browsing tools within Visual Studio, I just encountered other numerous declarations of bitmaps here and there, as well as image buffer pointers, and I don't seem to have found any discussion of whether they are useful, or even if we should steer well clear of using them for simulation stability concerns. I was madly trying to find a way to coax FSX cooperating with my need to use video memory, but it appeared hopeless :(

Ah - right. I think I can provide a sort-of answer to that but it comes from third-hand deepest memory via Bill and Susan Ashton(?) at ACES. Apparently much of the gauges.h file was supposed to be internal information only but the development community made so much use of it that to remove the 'internal only' stuff would have wrecked far more than it would have fixed; consequently ACES decided to leave it in but it was never documented. Bill may have to correct me....?But yes; some of the undocumented stuff is exetremely useful.-Dai

I hope the article there is helpful. I tried to make it as complete as possible, yet simple enough to understand! :(

Thanks Bill.....I took a quick look as I'm tied up with some other things at the moment, however it looked really goodand seems to talk about what I'd like to do. Thanks again :(

Hi DarrenAh - right. I think I can provide a sort-of answer to that but it comes from third-hand deepest memory via Bill and Susan Ashton(?) at ACES. Apparently much of the gauges.h file was supposed to be internal information only but the development community made so much use of it that to remove the 'internal only' stuff would have wrecked far more than it would have fixed; consequently ACES decided to leave it in but it was never documented. Bill may have to correct me....?But yes; some of the undocumented stuff is exetremely useful.-Dai

That does explain a great deal. I'm only a Flight Simulator whippersnapper, having entered the scene during the halcyon FS2004 days so I'm not aware of how long the SDK has been around. It would also explain why I see a number of Interfaces exposed in the SDK such as IGauge*.*, IPanel*.* etc. As far as my limited knowledge goes, interfaces are not usually publicly exposed in SDKs, certainly not without thorough documentation on the exposed methods anyway (something about going against encapsulation I think). Then again I'm speaking from a perspective of object-oriented programming and my impression is that the SDK is more C than C++. Thanks for that bit of history Dai :)If C gauges are still going to be with us in the next iterations of Flight Simulator, I sure hope things will become more thoroughly documented so everyone doesn't have to do so much 'reverse engineering' of a header file that has been released to help grow the adddon scene. I thought we would have been at that stage by now to be honest, but again, I'm not sure how long the SDK has been around.Most games companies are well aware of how a large and growing fan-base, twinned with commercial partners in crime, all creating their addons can lengthen shelf lives of products and also result in regularly successful sales of expansions and sequels. To keep and grow a fervent fan-base demands suitably thorough, well-maintained and clear SDK documentation for all areas of addon content (not just gauges).Hopefully, ESP will expand Flight Simulator technology interest to larger markets and any new revenue streams will result in Microsoft being able to fund further development of the SDK and, hopefully, this will filter down to we lowly Flight Simulator addon peons in the enthusiast market. I sure hope we won't see an emergence of a 'professional' SDK for those willing to pay big bucks, leaving an inferior SDK for the peasants. Sorry, my paranoia got the better of me there ;)