when to use classes and threads for multiple windows and networking

HI,

I'm writing an application that starts off with a small frame. On the
frame there is five buttons, each button opens up a new frame (not a
child frame, but a separate entity). Each new frame does something
different; one is a chat window, one transfers files, etc., but they all
open a new network connection to the server I wrote. Eventually the
program will be packed in to an exe file with the appropriate dll's and
distributed. My questions are these: Should each new frame that is
initiated from the originating program be a separate class in the
program? Also, should each separate frame be started in a new thread?
Currently the program works well, and all the network socket objects and
network sends and receives are separately threaded, so I believe no
blocking will occur there, but I'm still unsure how multiple windows
should be opened. If someone could pass an example program or show
where this is discussed, I would greatly appreciate it.

Thanks,

Rob

Rob McMonigal wrote:

HI,
I'm writing an application that starts off with a small frame. On the
frame there is five buttons, each button opens up a new frame (not a
child frame, but a separate entity). Each new frame does something
different; one is a chat window, one transfers files, etc., but they all
open a new network connection to the server I wrote. Eventually the
program will be packed in to an exe file with the appropriate dll's and
distributed. My questions are these: Should each new frame that is
initiated from the originating program be a separate class in the
program? Also, should each separate frame be started in a new thread?
Currently the program works well, and all the network socket objects and
network sends and receives are separately threaded, so I believe no
blocking will occur there, but I'm still unsure how multiple windows
should be opened. If someone could pass an example program or show
where this is discussed, I would greatly appreciate it.

Save yourself a lot of headaches later and do whatever it takes to pound this one thing into your head: There can only be one thread that interacts directly with the GUI. (Some platforms allow it, but wxWindows assumes that only one thread will be manipulating the UI.)

If you need worker threads to handle background tasks or socket comms that is fine, but they need to *not* invoke any methods on any windows directly. There have been several discussions and approaches presented on what to do instead, but probably the easiest is to simply call wxCallAfter(theWindow.someMethod, args) from the worker thread and then the call to theWindow.someMethod(args) will be actually done in the GUI thread during the next EVT_IDLE event.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Just curious: My impression was that CallAfter() did a PostEvent() and
so the call would really be made during the next pass of the event loop
(or the next N passes if some events were already in there). I didn't
think EVT_IDLE (which in turn seems to require WakeUpIdle()) had
anything to do with it...

···

On Tuesday 27 May 2003 09:48 pm, Robin Dunn wrote:

wxCallAfter(theWindow.someMethod, args) from the worker thread and
then the call to theWindow.someMethod(args) will be actually done in
the GUI thread during the next EVT_IDLE event.

--
Chuck
http://ChuckEsterbrook.com

Chuck Esterbrook wrote:

wxCallAfter(theWindow.someMethod, args) from the worker thread and
then the call to theWindow.someMethod(args) will be actually done in
the GUI thread during the next EVT_IDLE event.

Just curious: My impression was that CallAfter() did a PostEvent() and so the call would really be made during the next pass of the event loop (or the next N passes if some events were already in there). I didn't think EVT_IDLE (which in turn seems to require WakeUpIdle()) had anything to do with it...

Strictly speaking it doesn't, but it does help explain *when* it happens. The sequence of events goes something like this:

In MainLoop, the message queue becomes empty,
  send EVT_IDLE to wxApp
    in wxApp::OnIdle
      call ProcessPendingEvents
      call DeletePendingObjects
      call SendIdleEvents

So it is from the App's EVT_IDLE handler that the pending events (such as from wxCallAfter) will be processed, but before the EVT_IDLE event is sent to all the windows.

···

On Tuesday 27 May 2003 09:48 pm, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!