Andreas,

Thanks for the comments. When I started this crazy thing, I didn't
know if it would work at all as a plugin. I tried running the Squeak
interpreter as a separate thread within a wx app, and a bunch of other
combinations. But as I learned more about both the VM and wxWidgets,
I found that most of my hacks were not needed.

I'm sure you're right about the startup/shutdown patches being
unnecessary. The event handling is a tougher question. Currently I
need to have the VM ignore events destined for wx windows, because
if it doesn't, it conflicts with wx modal event processing. But if
I can replace the default wx modal loop, it might be possible to have
the VM dispatch all events. That would be great, since it would be
much more efficient than the separate polling process that is in
place now.

I'd love to get your take on the callback business. It's a real
mind-bender, so beer would definitely help.

.. Rob


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org]On Behalf Of
> Andreas Raab
> Sent: Wednesday, November 17, 2004 1:08 AM
> To: The general-purpose Squeak developers list
> Subject: Re: [ANN] wxSqueak update
>
>
> Hi Rob,
>
> > If you grab the source version from my site, you'll find the changes
> > in a file called win32-vm-changes.txt. I'll list them here as well.
> > Basically there's a call at startup, one at shutdown, and a patch to
> > the event handling to restrict the get/peek to the Squeak window.
>
> Thanks. I have a few questions about this (see below).
>
> > You might also be interested in the callback mechanism used for event
> > handling and method overrides. This uses a scheme you outlined some
> > time ago on this list, involving setjmp/longjmp and interpret(). I
> > think my current implementation is stable but unsatisfying. Callbacks
> > may occur at awkward times (e.g., while calling a primitive to create
> > a widget, or while handling another event), so a lot can go on in a
> > seemingly simple scenario. I had to resort to a clumsy 2-step process
> > to return values safely, but I'm sure there must be a cleaner way that
> > suspends/resumes processes in a manner that makes this unnecessary.
>
> Interesting. Yes, I'd be interested in discussing this some more
> but I'm not
> sure I can find the time right now (you should've come to OOPSLA - that
> would've been the best place to have a beer and yack about it).
>
> > sqWin32Intel.c (493)
> > -------------------
> >
> > #ifdef _WXSQUEAK
> > extern void wxExitApp();
> > extern void wxInitApp(struct VirtualMachine* vm);
> > #endif
>
> Question: In theory, it shouldn't be necessary to hack these changes into
> the win32 portion of the VM. When you create a plugin you can provide an
> initialiseModule() and shutdownModule() function which get called
> automatically when the plugin is loaded/unloaded or the system
> shuts down.
> What was the reason to put this into the win32 code?
>
> > sqWin32Intel.c (774)
> > -------------------
> > #ifdef _WXSQUEAK
> >  // for wx, we need to constrain peek/get to consider only the Squeak
> > window
> >  while(PeekMessage(&msg,stWindow,0,0,PM_NOREMOVE))
> >    {
> >      GetMessage(&msg,stWindow,0,0);
> > #else
> >  while(PeekMessage(&msg,0,0,0,PM_NOREMOVE))
> >    {
> >      GetMessage(&msg,0,0,0);
> > #endif
>
> Question: I would like to preserve the original behavior of the win32 vm
> pumping out all of the events from the queue unless there is a client for
> those events. Would it be possible for you to either use the message hook
> which is provided by the VM (it can be made so that it sees the events
> before the win32 vm touches them) or alternatively to tell the VM not to
> deal with these events (e.g., have a function call that says "don't touch
> any events whose window you don't own")?
>
> Cheers,
>   - Andreas
>
>
>