Win VM modifications

Andreas Raab andreas.raab at gmx.de
Thu Mar 3 14:38:49 UTC 2005


>> We just tried it, and no, it wouldn't harm regular Squeak at all. But it 
>> does seem to harm Areithfa Ffenestri support (see 
>> http://minnow.cc.gatech.edu/squeak/3862) quite severely.
>
> That certainly makes sense -- everything but your main window will be 
> ignored.

Well, it makes no sense whatsoever to me ;-) If wxWindows runs a mainloop I 
would expect it to drain the app event queue and dispatch all the events 
(just like the loop in ioProcessEvent does). If it would do so, then clearly 
Ffenestri should work (since the events would eventually get into the 
WndProc and passed up to Squeak) so the behavior of wxWindows is truly 
extraordinary.

It is really important to understand what a Windows app mainloop really 
does: If we have, e.g., the standard loop from sqWin32Window.c

  while(PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
    {
      GetMessage(&msg,NULL,0,0);
      DispatchMessage(&msg);
    }

then the following happens:
* PeekMessage: Will see if there are any events for *any* window in the 
app's event queue without removing it
* GetMessage: Will fetch the next event from the queue which may be for 
*any* window
* DispatchMessage: Will deliver the event to the *appropriate* window's 
WndProc (which is registered with the window when the window is created)

In other words: A window created by wxWindow *will* receive the event 
through the above mechanism in its registered WndProc. A mainloop like the 
above run by wxWindow *should* deliver events to *either* the main Squeak 
window or any other (e.g., Ffenestri-created) windows. The behavior of 
wxWindows apparently not adhering to either of the above two is extremely 
strange!

I would expect that the first version works (wxWindows does get the events 
synchronously in its WndProc!) *and* that the second version works - 
wxWindow should deliver the events to the appropriate WndProc, so you should 
be perfectly able to simply not to run ioProcessEvents *at all* (this would 
be a good test - if Squeak doesn't work when wxWindows runs the mainloop 
something is horribly broken).

> Well, this was the fundamental problem in getting two GUI systems to work 
> together, when each one wants to have the MainLoop. I'm not crazy about 
> the current scheme, but here's how it works. As we've discussed, the 
> Squeak loop is modified to ignore events to non-Squeak windows. At 
> startup, a process is run that checks every few milliseconds for an event 
> to a wx-window (ignoring events to the Squeak window).  When it gets an 
> event, it passes it through the normal wxWidgets processing. Not pretty, 
> but it works.

How does it check for the events? (can I see the source code?)

> Initially, I had hoped that I could tap into events after they arrived on 
> the Smalltalk side, assuming they had been augmented with window 
> information like your're doing with Areithfa Ffenestri. But Squeak events 
> are handled asychronously, and so much of the wxWidgets event processing 
> depends on them being handled synchronously that I just couldn't get it to 
> work.

I think you have a major bug in your thought process - as far as I can tell 
(and as far as I know Windows) your windows should get the events just fine 
(see above explanation). Unless there is some very strange magic in the main 
loop of wxWindows (do you have the source for the mainloop?) this ought to 
work with no further modifications.

Cheers,
  - Andreas





More information about the Wxsqueak mailing list