Virtual Application..., possible?

Well this one's been a tough one to search up for... Haven't found a single lead, but what I'm looking for essentially is a virtual machine, but would rather run another application contained inside of a panel or container of the sort.


Then if that's possible, to send commands back and forth between the two. That way the parent application can control the virtual(sub) application, and the virtual(sub) application can send back what it's doing at the same time-such as an event was risen, for that it would be risen for th parent application simultaneously.

hope it's possible;

thanks in advanced!

Now I'm thinking that it might be possible to pull the rug out from underneath the sub-program if you host it inside a separate AppDomain that your hosting application creates and has control over. That'd be my first line of investigation I think.

[Edit: To clarify, that's just the first idea that came into my head. Absolutely no idea if it'd work in the way you need it to.]
[Edit2: It would be simpler if it was a "known" application that you were hosting rather than potentially any windows executable.]

If you want to make a window from another process a child of a window in your app then you can use the SetParent API. That has no real bearing on communication though. They are two different processes so IPC between them is the same as it is between any other two processes.

I'd like to hear more about what you are thinking. After all, from that description, I see no reason to have multiple apps. The child app appears to need to have a UI, as you wanted to run it inside a container, and the parent app appears to need to have a UI, since it will have a container for the child app. What isn't clear is why this has to be two apps. The child doesn't sound like it has an existence outside the context of the parent, which really sounds like a fairly typical MDI application.

An alternate way of thinking about this would be two distinct apps that communicate between each other. How they appear on the screen is problematic, because the focus would have to be on just one of the apps at a time. Therefore, you could have the child app show a form that is always positioned at a certain place on the screen, while the main app would be made full screen. In fact, the child app could determine the location of the parent app form, and position itself relative to the location and size of that form, but the child app would always be on top of, or behind, the parent app, and only one will have focus at any one time (the MDI solution is one way to allow both to have focus).

Another alternative would be to just have two apps running on the same computer, with their location independent of each other. I have that for some robot code. The apps communicate via UDP packets, though there are many means of communication in this situation. I chose UDP because the apps are not necessarily located on the same computer, but could be anywhere on my home LAN. There are probably easier means of communication than that if the two will be on the same system, but the UDP code is all posted here in various places.

Quote:

---

Originally Posted by Shaggy Hiker

I'd like to hear more about what you are thinking. After all, from that description, I see no reason to have multiple apps. The child app appears to need to have a UI, as you wanted to run it inside a container, and the parent app appears to need to have a UI, since it will have a container for the child app. What isn't clear is why this has to be two apps. The child doesn't sound like it has an existence outside the context of the parent, which really sounds like a fairly typical MDI application.

An alternate way of thinking about this would be two distinct apps that communicate between each other. How they appear on the screen is problematic, because the focus would have to be on just one of the apps at a time. Therefore, you could have the child app show a form that is always positioned at a certain place on the screen, while the main app would be made full screen. In fact, the child app could determine the location of the parent app form, and position itself relative to the location and size of that form, but the child app would always be on top of, or behind, the parent app, and only one will have focus at any one time (the MDI solution is one way to allow both to have focus).

Another alternative would be to just have two apps running on the same computer, with their location independent of each other. I have that for some robot code. The apps communicate via UDP packets, though there are many means of communication in this situation. I chose UDP because the apps are not necessarily located on the same computer, but could be anywhere on my home LAN. There are probably easier means of communication than that if the two will be on the same system, but the UDP code is all posted here in various places.

---

The end was correct, actually. I do want some network communication going on.

The scenario is that on a managers PC there would be a satallite software. Which is simply a list docked to the left listing all stations connected through the network, and the rest is filled with a panel. Within this panel I'd like to display the current station that's selected in said list to the left. But not only would i be able to monitor the stations, you'd be able to control them as well.

This that thought in mind I began brain storming possible ways this could be done. I first though when the station is connected, it will be sent a packet signaling that it's being monitored(only when the satellite software has selected this station for monitoring). The station would take note of this and send back packets of information I could use to display and control simple tasks. But this has many disadvantages, biggest being the about of data being transferred could be become a problem.

So my second idea would to integrate the station software with the capability of sending and receive the basic mouse and key events. The way this would work is the station software would need to be ran coincide the satellite software and work just as such(sending and receiving mouse and key events). So essentially the satellite would be the middle man receiving packets from the station software, and forwarding them to the station software running coincide the satellite software(monitoring) and vice verse(controlling).

This made sense, but had a huge problem right of the bat(that being to run an application within another).. if it's not possible I can understand, I could always run the software separate and send messages back and forth between the station and satellite, while the satellite sends packets to the station connected to the network.