Hi -
> Why doesn't this make sense? If you use
> PeekMessage(&msg,stWindow,0,0,PM_NOREMOVE))
> you're only getting messages for the main Squeak window. And in my wx
> check, I'm only peeking for messages to windows other than the main
> Squeak window.
Yes, that part makes sense. The other didn't (why it wouldn't work just the
way it is).
> Well, I'm certainly no Win32 expert, so I can't say whether wxWidgets is
> strange, but its MainLoop does more than Peek/Get/Dispatch. If you have
> the stomach for it, take a look at the attachment, evtloop.cpp.
I see. My initial guess would be that there might be a problem with
wxEventLoop *wxEventLoopBase::ms_activeLoop = NULL;
not being set correctly.
> If I revert the original ioProcessEvents and turn off my event process,
> events do get delivered to wx windows, but it behaves very badly and
> generally crashes in short order.
Any chance of finding out where and why? The code doesn't look too ugly and
while there may be a few things which don't work it doesn't look like it
should just crash on you. Unless, of course, there is a bug (?) in something
like:
wxWindow *wndThis = wxGetWindowFromHWND((WXHWND)hwnd);
If code like this isn't aware that there might indeed be hwnds which are not
owned by wx, things might go nasty.
> And if events destined for wx windows
> are passed on to wxApp::ProcessMessage from ioProcessEvents, it works a
> bit better, but still crashes.
Again, any chance of finding out where it crashes?
> The only scheme I've found that works
> consistently is to poll for wx events in a separate Squeak process.
> I don't like it, but it works.
>> 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).
>
> That would be a good test, but I wouldn't be surprised if the funky
> stuff that goes on in ProcessMessage will screw it up for Squeak.
It doesn't look too funky to me. And again, if it crashes, knowing where it
crashes would be tremendously helpful.
>>> 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?)
>
> You can get all the wxSqueak source from my website, and all of the
> wxWidgets source from wxwidgets.org.
> The key part of the check is this:
>
> if (PeekMessage(&msg,0,0,0,PM_NOREMOVE)) {
> if (msg.hwnd != stWindow){
> GetMessage(&msg,0,0,0);
> if (!((wxSqueakApp*)wxTheApp)->ProcessMessage(&msg)){
> TranslateMessage(&msg);
> DispatchMessage(&msg);
> }
Interesting. What happens if you take out the test here:
> if (msg.hwnd != stWindow){
Does this crash? (this would clearly point to a problem in the wx libs).
> If it weren't for the ProcessMessage() call, this would be a "normal"
> loop.
Yes, and it should work just fine with Squeak.
Cheers,
- Andreas