How to realize data transmission between MFC application and orbiter

[xjflcf520]

I want to use C + + to make a software based on MFC dialog box, whether it can realize the data transmission between the software and orbiter, such as sending commands to orbiter or receiving data from orbiter

 

[kuddel]

Orbiter is not designed to be "remote-controlled".
Sending Windows-Messages to the Orbiter process might work (if you know what messages to send), but it's far from being nice and easy.
If you would like to get "telemetry data" from a simultated vessel for example, I would recommend something like this:

A orbiter module (DLL) that provides the link between Orbiter-API and your MFC-Dialog (via Windows-Messages for example).
Maybe an already existing addon[1] can be used or provide ideas on how to implement something similar.

[1] ...isn't there a "network client" addon thing?...Can't get the name from my head. I'll update the post if my head is more responsive again

... ORB:Connect was what I was trying to say ?​

 

[Urwumpe]

MFC? Isn't that already obsolete as hell?

 

[kuddel]

No problem with MFC. It's just a convenient wrapper around Win32 API and therefore a perfect fit for Obiter related things
...aaaand: if you are very quick and familiar with MFC, but extremely slow and inexperienced with - let's say .NET - I would always stay with the old stuff.

 

[Urwumpe]

No problem with MFC. It's just a convenient wrapper around Win32 API and therefore a perfect fit for Obiter related things
...aaaand: if you are very quick and familiar with MFC, but extremely slow and inexperienced with - let's say .NET - I would always stay with the old stuff.

I just ask because I started Win development with MFC, but at some point after 2015 found out, that Microsoft started to phase it out in favor of WPF, which you can also use in C++.

 

[xjflcf520]

Orbiter is not designed to be "remote-controlled".
Sending Windows-Messages to the Orbiter process might work (if you know what messages to send), but it's far from being nice and easy.
If you would like to get "telemetry data" from a simultated vessel for example, I would recommend something like this:

A orbiter module (DLL) that provides the link between Orbiter-API and your MFC-Dialog (via Windows-Messages for example).
Maybe an already existing addon[1] can be used or provide ideas on how to implement something similar.

[1] ...isn't there a "network client" addon thing?...Can't get the name from my head. I'll update the post if my head is more responsive again

... ORB:Connect was what I Is他和plug-inorbiterconnect​

Orbiter is not designed to be "remote-controlled".
Sending Windows-Messages to the Orbiter process might work (if you know what messages to send), but it's far from being nice and easy.
If you would like to get "telemetry data" from a simultated vessel for example, I would recommend something like this:

A orbiter module (DLL) that provides the link between Orbiter-API and your MFC-Dialog (via Windows-Messages for example).
Maybe an already existing addon[1] can be used or provide ideas on how to implement something similar.

[1] ...isn't there a "network client" addon thing?...Can't get the name from my head. I'll update the post if my head is more responsive again

... ORB:Connect was what I was trying to say ?​

Is The plugin orbiter connect？

 

[xjflcf520]

MFC? Isn't that already obsolete as hell?

because l am familiar with MFC

 

[Face]

If you are familiar with MFC, chances are you are so with C++ as well. In this case I'd suggest you write your own protocol to interact with Orbiter. While it should be possible in theory to hook Orbiter's main message queue in order to use windows messages for custom commands, I'd say IPC either via sockets or via anonymous pipes is the best way to go performance-wise. If you make it with TCP sockets, you can even do distributed systems.

However, given your other questions, I think what you want to do is to display the Orbiter rendering in your own application and control it from there as well. In this case I'd go with anonymous pipes and "SetParent"ing the window in.

 

[xjflcf520]

If you are familiar with MFC, chances are you are so with C++ as well. In this case I'd suggest you write your own protocol to interact with Orbiter. While it should be possible in theory to hook Orbiter's main message queue in order to use windows messages for custom commands, I'd say IPC either via sockets or via anonymous pipes is the best way to go performance-wise. If you make it with TCP sockets, you can even do distributed systems.

However, given your other questions, I think what you want to do is to display the Orbiter rendering in your own application and control it from there as well. In this case I'd go with anonymous pipes and "SetParent"ing the window in.

Yes ，what I want to do is like what you said ，and I have studied yout OMP client，but I have no idea how to realise it，can you be more specific thank you

 

[Face]

Usually, if you want to "hijack" a different process window, you first have to find the process ID. From there, you can get the main window handle. If you have it, you can do SetParent on this handle to set your own window as its parent. The window will then appear as sub-element in your window. You still have to handle resizing and such things, but mouse messages and the like should be fine.

For the anonymous pipe thing, you have to implement an Orbiter module that writes into one pipe and receives from another, both pipes that your father process set up before. You can transmit the appropriate IDs e.g. via Orbiter command-line parameters or by simple config files. You then have a bi-directional channel you can use to send bytes back and forth between your father process and Orbiter. What you encode in this bytes is then on your protocol you want to use. I'd suggest starting with a simple ASCII-based human-readable one that resembles PAR behavior, i.e. your father process sends a request, your Orbiter module reacts and acknowledges it, or in case of failure or timeout, the request is repeated. The requests could be encodings like e.g. "list vessels" to get the list of vessels in the simulation, followed by e.g. "update vessel <id> pos <x> <y> <z>", and so on. It really is up to your design of the protocol and what exactly you want to exchange with Orbiter.

 

[xjflcf520]

Thank you very much for your detailed answer. I should have some ideas

 

[xjflcf520]

Usually, if you want to "hijack" a different process window, you first have to find the process ID. From there, you can get the main window handle. If you have it, you can do SetParent on this handle to set your own window as its parent. The window will then appear as sub-element in your window. You still have to handle resizing and such things, but mouse messages and the like should be fine.

For the anonymous pipe thing, you have to implement an Orbiter module that writes into one pipe and receives from another, both pipes that your father process set up before. You can transmit the appropriate IDs e.g. via Orbiter command-line parameters or by simple config files. You then have a bi-directional channel you can use to send bytes back and forth between your father process and Orbiter. What you encode in this bytes is then on your protocol you want to use. I'd suggest starting with a simple ASCII-based human-readable one that resembles PAR behavior, i.e. your father process sends a request, your Orbiter module reacts and acknowledges it, or in case of failure or timeout, the request is repeated. The requests could be encodings like e.g. "list vessels" to get the list of vessels in the simulation, followed by e.g. "update vessel <id> pos <x> <y> <z>", and so on. It really is up to your design of the protocol and what exactly you want to exchange with Orbiter.

I want to know if the map in the map dialog box in orbiter is made by mapwingis

 

[Face]

I want to know if the map in the map dialog box in orbiter is made by mapwingis

I don't have the source code for Orbiter, so I can't answer that question. You'd have to ask Martin for this.
I can thus only guess, but judging by the information about that ActiveX control, I'd say that it looks like Orbiter is not using it.

 

[kuddel]

A look at Extended Map MFD (a.k.a. "Map MFD 2") source code could possibly give you ideas.
This however is an MFD, not an internal/external Dialog of Orbiter; it uses Orbiter-API and GraphicClient-API ( because it can );
your "standalone MFC-Dialog" might have to do a little more to achieve similar results.

 

[xjflcf520]

A look at Extended Map MFD (a.k.a. "Map MFD 2") source code could possibly give you ideas.
This however is an MFD, not an internal/external Dialog of Orbiter; it uses Orbiter-API and GraphicClient-API ( because it can );
your "standalone MFC-Dialog" might have to do a little more to achieve similar results.

Thanks for your advise

 

[xjflcf520]

I don't have the source code for Orbiter, so I can't answer that question. You'd have to ask Martin for this.
I can thus only guess, but judging by the information about that ActiveX control, I'd say that it looks like Orbiter is not using it.

Ok,thank you