the following setup: A standalone application should start a child process and then give its HWND handle back to the parent process so that it can be rendered there. So far this should be feasible with the HWNDComponent.
My question is, what is the best way to pass mouse and key inputs to the child process. Do I have to create a separate MouseInputSource that communicates via IPC with the parent process? Is there the same for Key events, a KeyInputSource? Or is there a simpler method.
mmmm… I’ve never tested anything like that, but is it really possible to communicate pointers like that between processes?
From what I understand about OS’s, anything related to pointers/memory access like HWND, ComponentPeer, etc, will not translate to correct values in another process as they’re not in the same address space.
Some Windows handle (HWND included) are valid for the whole desktop session, not just the process.
Interesting! I did not know that.
But that probably won’t be the case for any JUCE created pointers though?
The only communication that I need is:
- From parent to child: Mouse/Key events
- From child to parent: Window handle
All rendering/interaction logic happens in the child process, the parent only displays and forwords input events. If the child crashes the parent does not. That’s the idea at least I know that browsers have a seperate process for rendering, but I have no idea how they communicate. Anyway, no pointers needed.
MouseInputSource and MouseEvent are all implemented with a bunch of pointers, so I would imagine that whatever is in them won’t give you correct information in another process.
What I think will work is if you create your own struct where you copy all the information you care about from the event, like the position where it happened, modifiers, etc.
That was the plan. I need an IPC connection anyway, so passing the input event payloads serialized shouldn’t be an issue. I just need a way to inject the events once they are received by the child.
- Event in parent (on bounds of embedded HWND)
- Send to child
- Somehow inject event into the child process message loop
I think this step won’t work, it’s not really possible to inject fake events with JUCE, even though I got pretty close with a fake ComponentPeer when doing unit testing, it required faking the entire system so that you won’t receive any real events.
However, you can just pass this as a regular data structure and trigger some std::function that isn’t involving JUCE, and call it on the message thread of the parent process with callAsync.
Yep, I’ll have to think of another way. Thanks for the chat anyway.