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

FSW Compiling with FSW Simconnect Tips

WarpD said:
Ok... I will take a look at this as it should have worked. You should not have to explicitly load the DLL as it is already loaded by the sim. I have confirmed that FSW indeed loads the DLL.
Click to expand...
I'm fairly certain (although I have not tested it myself) that dll dependencies are not satisfied by the dll having been loaded by another process.
 
ddawson said:
What you will probably want to do is retrieve the FSW installation path from the registry. You can then safely call LoadLibrary to use dynamic linking to work with the current version of SimConnect.
Unless Dovetail start deprecating SimConnect functions, this approach will work regardless of the number of updates to SimConnect.
Click to expand...
This was my thinking as well. We have no WinSxS location for SimConect.dll, so retrieve the FSW root location that contains the DLL.
 
ddawson said:
I'm fairly certain (although I have not tested it myself) that dll dependencies are not satisfied by the dll having been loaded by another process.
Click to expand...
What are you loading directly from the DLL that the core SimConnect.h declarations don't provide? I am telling you, I do not load the SimConnect DLL in the Eaglesoft Citation X... simply connect to SimConnect with the SimConnect_Open function. So... why is this working for me if you are telling I must load the DLL myself and yet I am not?
Something in this discussion isn't adding up.
 
WarpD said:
What are you loading directly from the DLL that the core SimConnect.h declarations don't provide? I am telling you, I do not load the SimConnect DLL in the Eaglesoft Citation X... simply connect to SimConnect with the SimConnect_Open function. So... why is this working for me if you are telling I must load the DLL myself and yet I am not?
Something in this discussion isn't adding up.
Click to expand...
You're embedding a manifest in the gauge which tells it which version of SimConnect to load and the directory to find it in. The FSW version of SimConnect doesn't use a manifest.
 
The SimConnect.h that is in my FSW SDK "inc" folder embeds a manifest. That manifest wants SimConnect version "0.1.1073.999" So... what's different?
 
There is no corresponding entry in the WinSxS folder. If you embed that manifest in your program, it won't load, let alone run.
 
So... Dovetail has released an SDK that doesn't work as is? The Prepar3D v4 header has no manifest.
 
My first post in this thread described that the SimConnect .h needs to be altered for any programs to run. We need a C++ routine to read the registry key for FSW, and add a path to that directory.
 
Code: 
#include <shlwapi.h>    
#pragma comment(lib,"shlwapi.lib") 
#define FSW_REG_BASE TEXT("Software\\Dovetail Games\\Flight Sim World\\1.0")

LONG GetKey(TCHAR* pszBuffer, DWORD* pdwBufferSize)
    {     
    DWORD dwKeyType = REG_SZ;
    TCHAR default_val[] = TEXT("FSW not installed");   
    return SHRegGetUSValue( FSW_REG_BASE, TEXT("AppPath"), &dwKeyType, pszBuffer, pdwBufferSize, FALSE, default_val, _tcslen(default_val));
    }
 
The DLL path problem can be solved with a batch file running the program:
Code: 
set PATH=%PATH%;C:\Program Files (x86)\Steam\steamapps\common\FSW
OpenAndClose
pause

When the program exits, the batch file exits, and the PATH returns to it's previous state.

Also, an Application can have an App Path created in the registry:

Code: 
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\OpenAndClose.exe]
"Path"="C:\\Program Files (x86)\\Steam\\steamapps\\common\\FSW\\"

With that bit of registry code, OpenAndClose finds the correct path for SimConnect.dll. A problem here would be the program name being the same as another program for a different sim (FSX or P3D).

The problem with c++ SetDirectory, or registry App Path is that it must be done prior to running the program for implicit DLL calls. And that would require an installer program. The best solution is for Dovetail to put SimConnect.dll in the WinSxS where it belongs, and put the managed dll into the GAC where it belongs.

Another possibility is to run the program from a shortcut, and make C:\Program Files (x86)\Steam\steamapps\common\FSW as the Start in directory. The shortcut can then be placed anywhere. The problem is again, the enduser would need to make sure the path is correct for his FSW installation.
 
Last edited:
You must log in or register to reply here.
Back
Top