Why does SimConnect require a Window handle?

[Rob Ainscough]

I've always wondered why SimConnect requires a Window handle rather than an instance handle or PID?

For example:
1. WPF Application.xaml -- any code reference needed for SimConnect can't happen here because there is no window handle.
2. Windows Service -- again any code reference needed for SimConnect can't happen because there is no window handle.

For WPF, I have to create a window instance and work from that handle. But for Windows Service there is no associated UI. BUT why use a Window Handle (HWND) and not something like PID or HINSTANCE?

Cheers, Rob.

[EllipticCurve]

SimConnect is instantiated inside a windowed application (FS) and so the Window handle was used because Microsoft were short-signted (as usual) and didn't see it being used literally outside of a windowed environment.

[Rob Ainscough]

Yes, and oddly the "tradition" seems to be continued in MSFS.

Cheers, Rob.

[bertlaverman]

Actually, I have a C++ library that just ignores the damn thing, and it works fine:

Code: Select all

	log_.trace("connect(): Calling SimConnect_Open");
	hr = SimConnect_Open(&fsxHdl_, "SimConnectWorker", NULL, 0, 0, 0);

However, the Managed DLL wants to make things "easy" and requires it. Even worse: in the static C SimConnect.lib I can poll for messages, while the C# library only works when I hook into the Windows message loop. I was just about to ask if there was a way around this when I saw this thread. I'm kind of tempted now to dump this DLL and write my own.

Bert Laverman

[Rob Ainscough]

I'd love to see a managed .NET library that is essentially a wrapper to all the PDK functions. I'd even pay for one :)

Cheers, Rob.

[bertlaverman]

I was going there anyway, but I'm probably not going fast enough for you, because I have a full-time job as a Software Architect/Developer at AxonIQ, where I work in Java. What I have is up on GitHub, but very much the experiment/learning experience. Many different things tried out to see how best to approach it, but it is a C++ DLL with a C# UI.

The C++ stuff was originally aimed at building my own drivers for the Saitek Instrument Panels, after which I got "distracted" into the problem of a multi-play server, and constantly getting irritated at Windows UIs. I kind of got fed up with the Windows XP era UI building that is still there and wanted to move to C# for a WPF/XAML front end. Then I just patched a DLL interface on the code I had and it turned out to work fine. My conclusion is that the C/C++ part needs to be just interfacing/translating, so the engine (messaging loops, event/data registration, state machine) can be in C#, effectively throwing out most of the C++ stuff I have now.

[Rob Ainscough]

Hi Bert,

WPF for desktop apps is my preferred UI technology, I just need a nice .NET DLL (64bit) that I can use to access all the nice features in the PDK.

I'm not a big C++ programmer, exposure to it and have used it out of necessity when needed, but it's not something I use daily (this is not a judgement of the language just not something I use regularly). Also why I haven't done much with WASM on the MSFS side but sadly it would be impossible to do a WASM wrapper for .NET.

Could I ask for your GitHub link to what you have? PM me if you prefer or email at info@simhorizon.com

Cheers, Rob.

[bertlaverman]

Ok, yesterday, while working on the new library, I realized I have read over a single line in the docs on "SimConnect_CallDispatch" that explains a lot:

It is important to call this function sufficiently frequently that the queue of information received from the server is processed (typically it is coded within a while loop that terminates when the application is exited). However, if the project involves developing a library (DLL) rather than an application (EXE) then only one call to this function is necessary. This call will store the name of the callback in a cache, and whenever a packet is sent to the client, the callback function will be run.

What it never explicitly makes clear, is what exactly makes the difference between an EXE and a DLL project, until you look at the code example and realize it is about the window handle: For a DLL you pass zeroes and NULLs as I did in my C++ code. This NULL-handle is what makes SimConnect actively call the same dispatch whenever a message comes in. So just ignore that stupid handle, call SimConnect_CallDispatch once, and you can leave out a dispatch-loop as a bonus!