|
|
 | | From: | christian mader | | Subject: | GUI access with two threads | | Date: | Thu, 20 Jan 2005 09:35:35 GMT |
|
|
 | As written many times in this list only one thread should perform
GUI-operations. So every time my worker-thread has to do a Show() or a
Create() ist sends an event to the wxFrame class, containing a pointer to
the object wich is to be shown or created. The wxFrame gets the event,
casts to the appropriate class and does the event.pPointerToObject->Show()
or whatever GUI-function is needed.
1) Is this the way one should/can do this, or are there other/better ways?
At the moment it seems to work, but i feel a little bit uncomfortable with
this, so i'd like to hear your comments about this before going on (it's a
quite huge MFC->wxWidgets porting project i'm working on).
Sometimes i need the returned value of a Create() call in my worker thread,
so i'm sending an event from the GUI-Thread (wxFrame) to the worker thread
containing an int member with the Create() return value. So I'm using
ProcessEvent to transmit the event to the wxFrame and back to the worker
thread (which uses the return-value) since ProcessEvent is supposed to be
synchronous. On the other hand, when no return-value is needed i transmit
the event with AddPendingEvent (asynchronously).
2) Again my question: Does this seem correct to you or are there
other/better/easier ways to do this? I'm experiencing some segfaults, xlib
async and lost transmissions and i'm wondering if that's because i have
some forgotten GUI-calls in the worker thread.
Btw, i have some problems understanding what's exactly meant by 'GUI-Calls'.
Show() obviously seems to be a GUI-Call that should be only called by only
one thread. But how about Create() or SetPosition() and the other member
functions of, say, wxWindow?
tnx for reading and eventually replying to this :)
christian
|
|
|
