Hi,Some of you on the forum may remind a previous post of mine about the new C++ framework I've created for the Airliner XP Airbus. Now that the Wx500 for FSX is released, and since it is using the framework for its gauges, I wanted to share with you a little about how it looks like to create a gauge. This is a very simple example, taken from the actual DropStack XP gauge.The idea of the framework is to have a C++ abstraction layer to the SDK, as well as to provide a number of helper methods always used in all gauges, like keyboard shortcuts, sound, etc... Furthermore, the idea was to have a framework that is fully C++, i.e. no static macros, no compiled data structures to define elements like STATIC and NEEDLE. Also, the idea is that all elements are created dynamically in memory at run time, simply using the new operator, and the framework takes care to garbage collect everything created by the developer when the gauge exits.In addition, the framework offers enhanced and new features the SDK is not capable of, like support for 32 bits graphics, alpha blending, externally encrypted and pack resources (images, sound etc

How is your project coming? I'm in the process of creating something similar for my own use as well.What inspired you to do it, the Interface classes in the gauges.h? I noticed a lot of similarity to COM objects too.I was inspired by wxWidgets back when it was wxWindows, and I was learning that framework which got me thinking.Patrick

Thank you for asking!the FW has evolved a lot since this post, with many other features. The initial drivers were:1) get rid of the SDK in the gauge code through an abstraction layer, in order to cope with FS9/FS10/FS11 compatibility.2) offer a better experience to the customer with a feature set not possible with the SDK (32 bits graphics, alpha blending, animated color mouse cursors etc...)3) increase the reusability of gauges in different gauge pack (with the FW, each gauge is well defined as a class, and since there is not static compile time macros, reusing a gauge in another gauge pack is just a matter of #include the .hpp and calling new mygauge()4) increase maintainability of gauges over time. They are well defined/delimited classes and are easier to maintain, with the details of the implementation hidden in the FW itself.5) make available in the form of a well defined API the many out-of-the-box coding practises needed for nowadays professional gauges (keyboard shortcuts, sound, etc...)6) protect the IP of the gauge thanks to an externaly encrypted resource file7) optimize resources with very small gauge footprint (gauges released with the FW so far are about 500K) thanks to externaly packed resources, loaded at run time on demand (when needed only)and a couple other reasons.The direction it is taking now is to more and more get totally abstracted from the SDK. For now, it still relies internally on some SDK structures (the SDK elements, gauge headers, gauge rendering engine etc...). In the future, it will become a standalone authoring toolset for gauges that do not use the panel/SDK engine except for the I/O interface to variables (which later might even become abstracted as well with better implementation).At this time, one other developper is trained on the FW and already developping a gauge with it for Reality XP. It has became stable anre release grade since the FLT/N release (the Wx500 has been updated since then to accomodate the couple few changes).It now represents a 1+ year development already!What I'd be interested in knowing is what are the typical hurdles developper face with the SDK in designing gauges (not talking about the XML side of the gauges but the C/C++ side of it), in order to see how the FW can improve all this. In itself, the FW is already very effective for reducing time-to-market and to offer next-gen gauges with next-gen feature set.Jean-Luc

As a developer I'm uncomfortable with relying on a competing developer for any type of API/code.In my experience that tends to lead to conflicts, to put it mildly. So, even if you were to release such a product, I would be very unlikely to purchase it no matter the price.Now, if you completely shut down all other aspects of your business and relied soley on sales of your API... I'd purchase it if it was worth the cost.

As a developer too, my view is completely different than Ed's on this.I can think of many instances where a company produced a product or service that was then licensed to their competitors.An example is the recent agreement the US Postal Service has with Fedex, or Lufthansa Technik which provides aircraft maintenance services for some of their competitors.There is no conflict of interest here at all, its a fairly common occurence.I'd have no problem at all ponying up a license fee for the privilege of using such a framework if it allowed me to produce a better quality product, and/or saved me some development effort/time.Regards.Ernie.

Agreed, especially when in reality he would be providing most with technology they do not already have in house. So, if anything he would be providing competitors an advantage in that their gauges would be MORE functional than they are now.Always nicer to have something in house though so you can modify it. :)Patrick