• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.


There is barely a mention of them Ed. I've been tasked with seeing just how difficult it will be to migrate one of our simpler GA projects into FSW. So far I'm not too sanguine about the end result.
I noticed nothing regarding C/C++ based gauges. Did I miss it?

They published gauges.h and simconnect.lib. I did not invest my time in checking what has changed in gauges.h but my simple DLL gauge crash before reaching DLLStart function.

What is interesting that gauge callback extra_data parameter is still 32 bit in x64 architecture !!!!

FSAPI Callback(GAUGEHDR* gau, SINT32 serviceId, UINT32 extra_data);

so forget using extra_data to store pointers as in Microsoft's esp drawing gauges gdi example.
I actually changed the Callback definition to include a UINT64 as the third argument, rather than a UINT32.
I can get the gauge to load (I can see the tooltip drawn on the screen) but the gauge itself does not appear and its mouse function is never called.
I suspect that this has to do with the format of the bitmap files themselves, but without any documentation it seems pointless to try to debug this issue.
Doug, perhaps some hint might come from how XML bitmaps are now required to be .dds format. Is it possible that is the case with C++ gauges now as well?
Dxtbmp or imagetool are the most used tools. Imagetool normally comes with the sdk (although not with the FSW one).
Using VS2015, not that it should matter unless one is linking against a version dependent lib file.
I can attach the debugger to FSW, thereby discovering that while my custom tooltip is being drawn on the screen, the gauge has not remained in memory.
I've been playing with the FuelPressure.xml from the FSX SDK converted with GaugeConverter.exe from the FSW SDK.
Using this panel entry I got the gauge working in 2d.

gauge00=TestGauges!FuelPressure_d3d, 0,0,100,80

however I can't see it at all in the VC.

gauge00=TestGauges!FuelPressure_d3d, 0, 51

Does anyone have any idea why not?
I should have pointed out I'm trying to build a radio stack for the FSX c172 running in FSW and testing with this simple gauge.
I uploaded the gauge to the gauge forum.