PDK DLL with external app

[seippg]

Hi,

I wrote an app that uses Simconnect. Works pretty well. Now I'm thinking about porting it to use the PDK but I still want an external user interface. I'm thinking that a PDK DLL links directly to Prepar3D? If that's the case, my external app window would need a mechanism to communicate with it? If so, what is the best method of communication I can use between the DLL and my app? Is it possible to have a single instance DLL which links to both P3D and my app through their own respective interfaces? (E.g. one DLL loaded into memory that both apps talk to?)

Thanks!
Gregg

 

[ddawson]

This is one way:
https://msdn.microsoft.com/en-us/library/ms810613.aspx
The others that come to mind are named pipes and Windows sockets.

 

[seippg]

This is one way:
https://msdn.microsoft.com/en-us/library/ms810613.aspx
The others that come to mind are named pipes and Windows sockets.

Hi Doug,

Gosh, I guess I was too hopeful that I could use separate interfaces to call the same instance of a DLL. Having thought about it, I only need to send 'signals' to the DLL to reread a file from time to time...a byte or two. If I were to be able to create functions it would be like:

void RereadConfig() { // set a byte to have the other thread to reread the config file.

g_bRereadConfig = true;​

}

Then, in the P3D thread...

bool CheckConfig() {

if (g_bRereadConfig == true) {

g_bRereadConfig = false;
ReadConfig();​

}​

}

...if it were possible.

Seems a lot to manage a memory mapped file, named pipe or socket. Sockets are useful if it'll be between machines which I only lightly care about. It's been a long, long time since I've used named pipes to communicate between virtual machines on the same machine. Memory mapped files would work, no doubt, and are probably simpler than the other two.

Gregg

 

[ddawson]

Your dll could hook the P3D message queue and then you could use a user defined message, sent from your app to the P3D window.
Alternatively, you could use a windows event, although this would require a separate thread in the dll to wait on the event being set by your app.
I think I like the windows message queue approach better.

Having finished my second coffee...
Why not use a custom FS event, that your dll can watch for? Send it from your app with SimConnect_TransmitClientEvent.

 

[seippg]

Windows event...hmmm. That'd be easier. So, that DLL doesn't have a window so, I guess what you're thinking is to create a hidden window in the DLL with its own message queue. Then, in the client app, use FindWindow(NULL, szName). Interesting.

 

[ddawson]

You can use SetWindowsHookEx to make use of P3D's own message queue. You don't need to create a separate window.
Also, with the event, you just start a separate thread in your dll and use WaitForSingleObject:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx
You don't need the message queue at all.

 

[seippg]

Okay. If I can ask one more question. How do you debug these DLLs? Can you attach to it?

 

[ddawson]

Yes, P3D will accept the Visual Studio debugger.

 

[seippg]

So, you set a breakpoint in the DLL source code and then attach to a running instance of Prepar3d?

 

[seippg]

Hmmm...thinking through this DLL approach with P3D, perhaps there's a simpler way?