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.
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.
Signalflow:
Event in parent (on bounds of embedded HWND)
Serialize
Send to child
De-serialize
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.