Re-post to the win32-gui-users list, without the zip attachment, so that it goes through.
Rob.
On 30/07/07, Robert May <[EMAIL PROTECTED]> wrote:
> > On 29/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > > The whole reason for *not* running a message pump is to allow an
> > > embedding application to use PostThreadMessage() too. If we ran a
> > > message pump, we wouldn't know what to do with messages sent to hwnd
> > > NULL that we are not expecting.
>
> On 29/07/07, Robert May <[EMAIL PROTECTED]> wrote:
> > Right. But there are good reasons not to run a full message pump.
> > For example, from a Win32::GUI point of view I really don't want
> > win32_async_check to be dispatching keyboard messages for me - first,
> > I may want to be using a message pump with more complexity that simply
> > doing a TranslateMessage/DispatchMessage - I may want to dela with
> > dialog messages (IsDialogMessage()) and accelerators
> > (IsAcceleleratorMessage()). I think it would be very confusing if,
> > for example, sleep() started behaving like this.
>
> Thinking about this further it would be worse than confusing - it
> would potentially result in incorrect ordering of messages:
>
> Imagine I write XS with thin wrappers to GetMessage, TranslateMessage
> and DispatchMessage, such that I could write perl code somthing like
> this:
>
> while(my $msg = GetMessage()) {
> TranslateMessage($msg);
> DispatchMessage($msg);
> }
>
> Now I can end up in win32_async check between any 2 perl calls, and
> say I had just pulled a WM_KEYDOWN message. TranslateMessage pushes a
> WM_CHAR message onto the top of the queue. If I end up in
> win32_async_check between the TranslateMessage and DispatchMessage
> calls, and it pumps keyboard messages, then the WM_CHAR will be
> delivered before the WM_KEYDOWN. This would at best be confusing, and
> more likely break applications.
>
> I think the approach that win32_async_check takes currently is almost OK.
>
> Attached is a patch to win32.c (against AS build 819). It implements
> most of what I've talked about, plus a few other bits.
>
> Highlights:
>
> - QS_SENDMESSAGE added to wim32_msgwait to solve the DDE problem.
>
> - I've left QS_ALLMESSAGES in win32_msgwait, rather than using the
> QS_POSTMESSAGE|QS_TIMER that we did in build 820 and blead, I think
> it's better.
>
> - I've wrapped the PostMessage(.... PM_NOREMOVE) in win32_async check
> in a while() loop, to ensure that all messages get marked read - I can
> see occasions when there are multiple messages in the queue, and
> win32_msgwait/win32_async_check spin a couple of time to mark them all
> read, we now only get one loop. I've re-factored the function to move
> the PeekMessage loop to the end, so that I don't have to have it and
> the signal dispatch code twice.
> added another PostMessage loop (this is now very similar to the patch
> I proposed to solve the bug that caused use to change the QS_* flags
> for build 820/bleed.
>
> - the message pump part of win32_async_check now re-posts WM_QUIT
> messages (needed to play nicely with other message loops)
>
> - I've moved the message handling from win32_async_check to it's own
> function: win32_process_messages(), which can process either thread or
> window messages.
>
> - I've created a windows class for our message window, and made it's
> window procedure call win32_process_messages(). win32_async_check() now
> does a Translate/Dispatch message if we have a message window. This
> means that if we have a message window we won't lose messages from
> someone else's message loop.
>
> - I've added a hook procedure to handle the thread messages, if we
> don't have a message window. win32_async_check calls it using
> CallMsgFilter if it ever retrieves a thread message. This now means
> that we won't lose any thread messages in other modal loops, so long
> as those loops do a CallMsgFilter() - All Win32 OS modal loops do
> this (including message boxes, menus, window-resizing/moving etc.);
> we should encourage all other GUI packages (e.g. Tk,
> Win32::GUI) to make this call at appropriate times.
>
> - The hook procedure passes thread messages that we might be
> interested in to win32_process_message, and returns true if we process it;
> it passes it along the hook chain if we don't process it. This allows someone
> else using thread messages, in the case where we don't have a message
> window, to call SetWindowsHookEx to install their own handler to catch
> thread messages that we pull off the message queue.
>
> I think I've covered most bases. I can't run the test suite, as it
> throws too many errors on Win98. I'll try to do it on Win2K in the
> next couple of days.
>
> I also attach a couple of scripts that exhibit some of the
> problems I was trying to eliminate. They are documented in the
> scripts themselves.
>
> Still TODO:
> - I need help getting some of the
> PERL_IMPLICIT_CONTEXT/MULTIPLICITY/whatever ifdefs right. The context
> passing is a bit complex, as we can't change the signature for the
> window procedure callback to include a context, but I've coded a way
> round this.
> - I'd like to see us using registered messages rather than WM_USER_*
> macros. This would avoid us ever clashing with someone else's message
> numbers (this is only a potential problem for thread messages, not
> when we have a message window)
>
> A lot of the complexity of the context passing could be removed if we
> were to agree to take the hit of doing a dTHX; in
> win32_process_message. We don't go in there very often (only for
> alarms, kills and forks (and thread creation?). Perhaps the overhead
> is worth the reduction in complexity?
>
> I will re-iterate: all that is actually needed to solve the original
> DDE initialisation problem that started this discussion is to add
> QS_SENDMESSAGE to the MsgWaitForMultipleObjects line in
> win32_msgwait(). All the rest of this stuff would be 'nice to have'
> so that Win32::GUI, Tk and other gui tookits can play nicely with perl
> on Win32.
>
> I hope this is useful,
> Regards,
> Rob.
>
>
--
Please update your address book with my new email address:
[EMAIL PROTECTED]
win32.c.patch
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Perl-Win32-GUI-Users mailing list Perl-Win32-GUI-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users http://perl-win32-gui.sourceforge.net/
