• 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.

How to execute_calculator_code

M

MartinLoga

Messages
34
Country
switzerland
Hi,

I don't get the concept around execute_calculator_code (I'm using Prepar3D 2.2 SDK). Need some directions here.

So my scenario is to control a gauge from an application.

According to some documentation around execute_calculator_code it seems like I can set variables of a gauge with it.

So at first I basically called something like execute_calculator_code(" 1 (>L:foo, Enum)", NULL, NULL, NULL); but then I got a linkage error called "unresolved external symbol _ImportTable"

Where do I get that Table from?
And how does it work in general that prepar3d knows about variables defined in models?

Thanks for your help
 
ImportTable is a structure that is created as part of a gauge or other in-process dll file. FS populates the structure with data when the gauge/module is loaded.
You can't use execute_calculator_code from a stand alone application. You will need a C gauge or module as a shim for that.
 
Thanks for the link. Have been there before.

@dawson: OK so it has to be a dll.
But Than I'm curious. I have here some code linked against FSX10 SDK that does not create that structure and just uses it. So there is no GAUGE_TABLE_BEGIN or something related (not allowed to show you that code). Somehow that gauges are defined only within the model data. The only difference I see is ImportTable vs. Panels.
 
MartinLoga said:
Fortunately I can ask the original developer. Apparently it exploits a bug in FSX10.
Click to expand...

I saw that you posted the same question over at the P3D forum. You might want to consider that the same 'bug' might not exist in P3D. Even if it does now, there is no guarantee that it will exist future versions.
I would strongly suggest that you build your gauge with C, rather than xml. You could then use a private data area and/or client events to allow your external application to communicate with the gauge.
 
Doug, this is not about a gauge, rather about animations and visibility.

Not a "bug" per se. More of a "hack"... If I am right about what bug Martin refers to, closing it in new SDK will actually make it little easier to make the hack work. (as it is now, this kind of hack requires not only to refer to the gauges SDK, but requires the programmer to modify the gauge header a tiny bit.)

I'll have to take a look at my code to write a proper analysis of this.
 
So I took a look - the changes from 2.0 to 2.2 SDK in gauges seem to be inconsequential - just adding some more key events in gauge header.

As for the change required - the mentioned hack. By default gauges header #defines functions by refering them to the ImportTable member structure PANELSentry, which contains a pointer to PANELS struct (which contains function pointers).
The change required lies in modifying the #define directive to refer to PANELS struct by pointer directly. (thus bypassing ImportTable)

This was discussed in this forum several years ago.
 
Is this still about "unresolved external symbol _ImportTable"?

If so I think that is a problem with not including the FS libs in your build? I'm not a C expert (most of the time I just stumble along) but I was getting some of those errors and I think that was the problem (can't remember the exact details anymore).
 
Anthony31 said:
Is this still about "unresolved external symbol _ImportTable"?

If so I think that is a problem with not including the FS libs in your build?
Click to expand...

Not in this case. ImportTable contains a PANELS structure filled by FS at runtime. To access the set of C functions (ie execute_calculator code, etc) described in the SDK through a standalone application it would be necessary to:

- Include in the .exe a modified version of gauges.h in where all functions originally linked to ImportTable.PANELSentry.fnptr now be linked to Panels.
- Include EXTERN_C __declspec(dllimport) PANELS *Panels = NULL in the .exe source.
- Build a tiny custom module (.dll) with a function to make FS fill the exported Panels pointer. This module has to be loaded by FS through DLL.XML reference file.

I think this should work ok.

Tom
 
Last edited:
You must log in or register to reply here.
Back
Top