Re: Initializing the GUI from a different thread

   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;

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".

------ Original Message ------
From: [email protected]
To: "Wuping Xin" <[email protected]>; "FOX Users" 
<[email protected]>
Sent: 2/28/2022 9:59:04 AM
Subject: Re: [Foxgui-users] Initializing the GUI from a different thread

>On 2022-02-28 08:32, Wuping Xin wrote:
>>"Just for my understanding: This means under windows it always needs
>>to be the main thread which calls FXApp::run?"
>>
>>First thank you for the SUMO project.  I am a user of it.
>>
>>-  Yes.  For Fox Toolkit Windows application, the main thread (which
>>is where the entry function main() is called),  and the main UI thread
>>(which is where MainWindows and other UI elements are created), must
>>be the same thread.
>>
>>This is because -  dispatchEvent will be invoked in the context of the
>>main thread, which maintains the message loop and has all the relevant
>>internal dispatchMesage/translateMessage WIN32 call wrapped as part of
>>FxApp's methods.
>>
>>If you spawn a separate thread, where you call   MainWindow*
>>mainwindow=new MainWindow(&application)  -  that separate thread won't
>>have WinProc defined/registered thus there won't be any proper message
>>loop/dispatching.
>
>As I understand it, it doesn't have anything to do with the WinProc;
>rather, when a window is created its is associated with the thread's
>event queue [one of which will be created if it didn't exist].
>
>The WinProc is just a subroutine that processes the events; since
>we don't assume responsibility for borders, title bar, and other
>decorations, we'll use the built-in processing for that.  Other
>stuff we intercept and pass along through the FOX system.
>
>But for all intents and purposes, a WinProc is just a routine that
>can be executed by any thread [of course I don't recommend it if
>other threads may execute same proc on same window, havov is sure
>to follow].
>
>The message queue is the important thing.  Its per thread....
>
>
>   -- JVZ