Hi, I dont know much about the message queue works on Wine but wondered if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact. As I understand it, running two instance of command line wine is more analogous to having two different computers running each app under windows. My goal is getting NatSpeak dictated text messages freed from the confines of the wine instance of the app. This would seem to be one approach if wine can run more than one process at a time. TIA.
On Tue, Nov 01, 2005 at 08:03:07PM +0100, wino(a)piments.com wrote:
Hi,
I dont know much about the message queue works on Wine but wondered if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact.
As I understand it, running two instance of command line wine is more analogous to having two different computers running each app under windows.
My goal is getting NatSpeak dictated text messages freed from the confines of the wine instance of the app. This would seem to be one approach if wine can run more than one process at a time.
Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that. Ciao, Marcus
On Tue, 01 Nov 2005 21:54:51 +0100, Marcus Meissner <marcus(a)jet.franken.de> wrote:
My goal is getting NatSpeak dictated text messages freed from the confines of the wine instance of the app. This would seem to be one approach if wine can run more than one process at a time.
Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that.
Ciao, Marcus
Many thanks, that is indeed what happens. And the best part: Dragon can actually type into editboxes on a concurrently running app! None of the voice control stuff works, even internally, so I may get to looking into that mechanism later to see if it can be made to work. (eg "click file" should bring down the file menu) Indeed this seems to upset the dictation function and leaves it in an inconclusive state . Playing back some text seems to clear it tho'. fixme:menu:GetSystemMenu not supported on other process window 0x1401f2 fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub This does not look too far from working either. Now the big one here is to get this output sent to Linux programs. I have been considering different routes to this end. 1/ Using winedebug or spy output piped through grep then somehow injecting it into various X programs. 2/ Patching something into wine or better hooking into and existing mechanism that could send the output to the X window with the input focus. 3/ Using wininet to open a link to a bespoke client on 127.0.0.1 that could redirect the output in X. As you can see are barely thought out ideas just to map possible ways to explore. Any comments on the merit of any of these approaches? TIA
At 01:54 PM 11/1/2005, Marcus Meissner wrote: <snip>
Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that.
Ciao, Marcus
So I could create 2 wine apps that simply duplicate the window creation and message handling , and have them use FindWindow and the like to enable using SendMessage and such to synchronize the windows? If so, that would MUCH simpler than the method I had started formulating.
I was going to wait til tomorrow to test this, but couldnt wait. This works perfectly for my app and couldnt have came at a better time. I just created a simple Win32 dispatcher program for each screen and sent the window creation messages to the HWNDs from FindWindow instead of the local app and it creates the dialogs on any screen I want. Joy Joy!!!!! It worked out perfectly since the threads that create windows have to send messages to the main loop for it to create them so that the dialogs dont from close when the thread exits anyway. It is refreshing that after I went through all the battles of getting multihead display, gcc, and wine running on Solaris that FINALLY something would work so simply. Thanks again to the whole Wine crew that made this possible!!! At 04:26 PM 11/1/2005, Rob D wrote:
At 01:54 PM 11/1/2005, Marcus Meissner wrote:
<snip>
Running two "wine foo.exe" will act as if on the same machine, including interchange of windows messages if the apps do that.
Ciao, Marcus
So I could create 2 wine apps that simply duplicate the window creation and message handling , and have them use FindWindow and the like to enable using SendMessage and such to synchronize the windows?
If so, that would MUCH simpler than the method I had started formulating.
I dont know much about the message queue works on Wine but wondered if there was means of running two progams in the same context on wine in such a way that they use the same message queue and can therefore potencially interact.
As I understand it, running two instance of command line wine is more analogous to having two different computers running each app under windows.
Wouldn't those share the same wineserver, and thus be able to message to each other etc.? Kuba
participants (4)
-
Kuba Ober -
Marcus Meissner -
Rob D -
wino＠piments.com