-
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.
"execute_calculator_code" in Managed Code ?
- Thread starter Geoff_D
- Start date
As far as I know, this ability is only available through the panel interface provided to an in-process gauge or module (native DLL), and not provided via the SimConnect API.
The panel interface is a pointer populated by FS when it loads in-process DLLs. It provides access to gauge variables and the gauge API functions, including this one to bridge XML gauges with C++ gauges.
It is possible to do this from managed code, yet it seems an uphill battle. Some options include
1a) you must run the CLR as an in-process DLL (see my example code in this forum).
1b) you must map the function in your CLR loader DLL to the managed equivalent via a DLLImport statement.
2) you can write a small DLL using sockets or some communication library such as MSMQ or COM+ to communicate with an out of process DLL your managed code talks to.
Loading the CLR inside the FS process space, outside of its complexity, is a memory hog. It almost guarantees an OOM based on my tests on a machine with 2Gb of memory, even if you use your own memory manager to mitigate the dangers. Not so much a problem on 64 bit operating systems with 4Gb memory, but that is still not very common out there.
The other option may serve you better, and it is quite complex as well. It seems no matter what, native code is needed somewhere to get to this function.
Probably the easiest is to get ACES to include that in the next API release, especially with the very strong push of XML only features
Now someone is going to say to me, read page 5 of the manual and here's one line of code on how to do it...
Etienne
The panel interface is a pointer populated by FS when it loads in-process DLLs. It provides access to gauge variables and the gauge API functions, including this one to bridge XML gauges with C++ gauges.
It is possible to do this from managed code, yet it seems an uphill battle. Some options include
1a) you must run the CLR as an in-process DLL (see my example code in this forum).
1b) you must map the function in your CLR loader DLL to the managed equivalent via a DLLImport statement.
2) you can write a small DLL using sockets or some communication library such as MSMQ or COM+ to communicate with an out of process DLL your managed code talks to.
Loading the CLR inside the FS process space, outside of its complexity, is a memory hog. It almost guarantees an OOM based on my tests on a machine with 2Gb of memory, even if you use your own memory manager to mitigate the dangers. Not so much a problem on 64 bit operating systems with 4Gb memory, but that is still not very common out there.
The other option may serve you better, and it is quite complex as well. It seems no matter what, native code is needed somewhere to get to this function.
Probably the easiest is to get ACES to include that in the next API release, especially with the very strong push of XML only features
Now someone is going to say to me, read page 5 of the manual and here's one line of code on how to do it...
Etienne