Re: Initializing the GUI from a different thread

Hi Jeroen, hi Wuping Xin, hi all,

Am 28.02.22 um 16:32 schrieb [email protected]:
> On 2022-02-28 09:14, Wuping Xin wrote:
>> FXApp.cpp, line 1432 (and several other places),  isn't this the
>> WndProc registration with the WndClass, as required by Win32 GUI
>> programming?
>>
>>   wndclass.lpfnWndProc=(WNDPROC) FXApp::wndproc;
> 
> Absolutely!  This is the main window proc.  But its fed by
> the message queue [getNextEvent() grabs them from there].
> 
> 
>> And WndProc in turn, calls app->dispatchEvent, which propels the
>> message queue in the current thread context (i.e., the main thread).
>>
>> FXival CALLBACK FXApp::wndproc(FXID hwnd,FXuint iMsg,FXuval
>> wParam,FXival lParam){
>>   return app->dispatchEvent(hwnd,iMsg,wParam,lParam);
>>   }
>>
>> But of course, each thread has its own message queue that belongs to
>> its isolated thread context.   The UI thread spawned separately,
>> however, does not have message dispatching needed by the UI  -  all
>> messages would end up in a "black hole".
> 
> Well, that's how windows is organized.  On Linux/Unix, the event queue
> does not belong to any particular thread and events are delivered to
> whomever pulls them from the queue. [just not do all threads at once,
> please!].
> 
> The best we can do, in portable applications, is to have a single
> thread manage the GUI.  You can have as many worker threads as you
> want, however.  So its a division of labor issue.

I have to admit I have a hard time following your discussion, so I just 
want to describe my problem in more detail.

We already have python bindings for sumo called libsumo where the user 
can start the simulation and modify it from her python script the way 
she likes. Now we want to do the same thing with sumo-gui where the 
obvious thing to do (namely call app.run() when the user starts the sim) 
does not work because run() does not return until the app is finished 
and the second most obvious thing trying to move run() (and all the 
other GUI initialization stuff) to another thread seems not to work on 
Windows as well.

So is this a FOX limitation which might get fixed in a future version?
Or is this in general not feasible on Windows (or would need a major 
rework of FOX) and we should simply start a separate GUI process and 
stick to doing things with interprocess communication here?

Thanks for your advice,
Michael


_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users