2007/7/31, [EMAIL PROTECTED] <
[EMAIL PROTECTED]>:
>
> Send Perl-Win32-GUI-Users mailing list submissions to
> perl-win32-gui-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Perl-Win32-GUI-Users digest..."
>
>
> Today's Topics:
>
> 1. Re: Why is my GUI hanging? (Jan Dubois)
> 2. Re: Why is my GUI hanging? (Robert May)
> 3. HWND_MESSAGE on Win98 [Was: Why is my GUI hanging?] (Robert May)
> 4. Re: HWND_MESSAGE on Win98 (Jan Dubois)
> 5. Re: HWND_MESSAGE on Win98 (Robert May)
> 6. Re: Why is my GUI hanging? (Robert May)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 28 Jul 2007 18:04:26 -0700
> From: "Jan Dubois" <[EMAIL PROTECTED]>
> Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
> To: "'Robert May'" <[EMAIL PROTECTED]>
> Cc: perl-win32-gui-users@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sat, 28 Jul 2007, Robert May wrote:
> > On 28/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > > CreateProcess() will return and not wait for command.com/cmd.exe to
> > > initialize. Upon return win32_spawnvp() will call win32_msgwait(),
> > > which should continue to pump the message loop until the external
> > > process ends.
> >
> > That's what's supposed to happen, but in AS build 819 on win98 (that's
> > all I have access to this weekend), I have to change the flags to
> > MsgWaitForMultipleObjects from QS_ALLEVENTS to
> > QS_ALLEVENTS|QS_SENDMESSAGE to get it to pump the sent WM_DDE_INITIATE
> > message.
>
> Alright, I looked at the code again, and the real problem is:
> win32_msgwait() doesn't actually dispatch any messages; it only
> processes (via win32_async_check()) WM_TIMER and WM_USER messages sent
> to hwnd NULL.
>
> 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.
>
> But given the problem you discovered with DDE initiation while waiting
> for system() to return, I think win32_async_check() needs to run a
> message pump. Given that the whole PostThreadMessage() mechanism is too
> brittle for GUI threads anyways (you cannot avoid losing messages), I
> doubt anyone is using it while also embedding Perl.
>
> While looking at this issue I noticed that even though we are using a
> message-only window on Windows 2000 and later, we are not actually
> expecting anybody else to dispatch the messages to a wndproc; we always
> try to snatch them out of the queue via PeekMessage(). So we still
> inherit the brittleness of the PostThreadMessage() mechanism.
>
> I'll see if I can come up with a patch for both issues some time later
> next week.
>
> Cheers,
> -Jan
>
> PS: Please let me know if you happen to know a mechanism to create a
> message-only window on 98/NT (a window that is not top-level and
> will not receive broadcast messages). If this were possible, then we
> could get rid of PostThreadMessage() completely.
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 29 Jul 2007 13:19:52 +0100
> From: "Robert May" <[EMAIL PROTECTED]>
> Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
> To: "Jan Dubois" <[EMAIL PROTECTED]>
> Cc: perl-win32-gui-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 29/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > On Sat, 28 Jul 2007, Robert May wrote:
> > > On 28/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > > > CreateProcess() will return and not wait for command.com/cmd.exe to
> > > > initialize. Upon return win32_spawnvp() will call win32_msgwait(),
> > > > which should continue to pump the message loop until the external
> > > > process ends.
> > >
> > > That's what's supposed to happen, but in AS build 819 on win98 (that's
> > > all I have access to this weekend), I have to change the flags to
> > > MsgWaitForMultipleObjects from QS_ALLEVENTS to
> > > QS_ALLEVENTS|QS_SENDMESSAGE to get it to pump the sent WM_DDE_INITIATE
> > > message.
> >
> > Alright, I looked at the code again, and the real problem is:
> > win32_msgwait() doesn't actually dispatch any messages; it only
> > processes (via win32_async_check()) WM_TIMER and WM_USER messages sent
> > to hwnd NULL.
>
> PeekMessage() will dispatch sent messages, (apparently) regardless of
> the filtering applied. Certainly on Win98 all I have to change to fix
> this particular DDE problem is to add QS_SENDMESSAGE to the
> MsgWaitForMultipleObjects() to get it to return if there is a sent
> message in the queue - even if I've called alarm(0); to make
> w32_hwnd_message not equal to INVALID_HANDLE_VALUE, so that we do the
> 'thread message only' PeekMessage, the DDE problem is gone.
>
> > 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.
>
> 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.
>
> > But given the problem you discovered with DDE initiation while waiting
> > for system() to return, I think win32_async_check() needs to run a
> > message pump.
>
> I think it's already doing enough. The DDE problem is that
> MsgWaitForMultipleObjects isn't returning for the *sent*
> WM_DDE_INITIATE message.
>
> > Given that the whole PostThreadMessage() mechanism is too
> > brittle for GUI threads anyways (you cannot avoid losing messages), I
> > doubt anyone is using it while also embedding Perl.
>
> I wouldn't bet on it. What we should do is put a call to
> CallMsgFilter() in any message pump loop we have that might pull
> thread messages off the queue, to give someone else a chance to see
> then, if they need to (See
> http://blogs.msdn.com/oldnewthing/archive/2005/04/28/412574.aspx for
> more info)
>
> > While looking at this issue I noticed that even though we are using a
> > message-only window on Windows 2000 and later, we are not actually
> > expecting anybody else to dispatch the messages to a wndproc; we always
> > try to snatch them out of the queue via PeekMessage(). So we still
> > inherit the brittleness of the PostThreadMessage() mechanism.
>
> This is a problem that I have on my list of things to look at. In
> particular, even if we're using a message-only window, someone else's
> message pump (e.g the one run by Win32::MsgBox, may pull our messages
> from the queue and translate/dispatch them. As we are not handling
> the messages in the window's wndproc, they never get processed.
>
> > I'll see if I can come up with a patch for both issues some time later
> > next week.
>
> Currently I'm leaning towards just adding QS_SENDMESSAGE to the
> MsgWaitForMultipleObjects() call - we'll need to do this anyway to
> solve the DDE problem, and I think it's a small enough change to
> propose for 5.10. I think anything else we do will be a much bigger
> change, and will probably have to wait for after that.
>
> I'll spent some more time thinking about this during the week.
> Should we move this discussion to P5P?
>
> > PS: Please let me know if you happen to know a mechanism to create a
> > message-only window on 98/NT (a window that is not top-level and
> > will not receive broadcast messages). If this were possible, then we
> > could get rid of PostThreadMessage() completely.
>
> I'm not aware of a way, but I'll do some research. I'm pretty sure
> that we don't wan ta real top-level window ....
>
> Regards,
> Rob.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 29 Jul 2007 15:59:33 +0100
> From: "Robert May" <[EMAIL PROTECTED]>
> Subject: [perl-win32-gui-users] HWND_MESSAGE on Win98 [Was: Why is my
> GUI hanging?]
> To: "Jan Dubois" <[EMAIL PROTECTED]>
> Cc: perl-win32-gui-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 29/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > PS: Please let me know if you happen to know a mechanism to create a
> > message-only window on 98/NT (a window that is not top-level and
> > will not receive broadcast messages). If this were possible, then we
> > could get rid of PostThreadMessage() completely.
>
> I can't speak for WinNT, as I don't have it available, but on Win98,
> using HWD_MESSAGE as the parent window to CreateWindowEx() appears to
> work fine (despite what MSDN says). Using it I end up with a window
> that is a child of a hidden system window. The window is not top
> level, not visible, and I can't make it receive a broadcast message.
>
> As soon as I can get back in front of a Win2K box I'll look to see if
> the implementation looks the same there.
>
> Regards,
> Rob.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 30 Jul 2007 00:45:40 -0700
> From: "Jan Dubois" <[EMAIL PROTECTED]>
> Subject: Re: [perl-win32-gui-users] HWND_MESSAGE on Win98
> To: "'Robert May'" <[EMAIL PROTECTED]>
> Cc: perl-win32-gui-users@lists.sourceforge.net
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, 29 Jul 2007, Robert May wrote:
> > On 29/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > > PS: Please let me know if you happen to know a mechanism to create a
> > > message-only window on 98/NT (a window that is not top-level and
> > > will not receive broadcast messages). If this were possible,
> > > then we could get rid of PostThreadMessage() completely.
> >
> > I can't speak for WinNT, as I don't have it available, but on Win98,
> > using HWD_MESSAGE as the parent window to CreateWindowEx() appears to
> > work fine (despite what MSDN says). Using it I end up with a window
> > that is a child of a hidden system window. The window is not top
> > level, not visible, and I can't make it receive a broadcast message.
>
> I've seen at least anecdotal evidence that using HWND_MESSAGE on 98 might
> be somewhat dangerous:
>
> http://www.virtualdub.org/blog/pivot/entry.php?id=153
>
> So I'm not sure if we want to ignore MSDN on this point.
>
> Cheers,
> -Jan
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 30 Jul 2007 20:11:24 +0100
> From: "Robert May" <[EMAIL PROTECTED]>
> Subject: Re: [perl-win32-gui-users] HWND_MESSAGE on Win98
> To: "Jan Dubois" <[EMAIL PROTECTED]>
> Cc: perl-win32-gui-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 30/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > On Sun, 29 Jul 2007, Robert May wrote:
> > > On 29/07/07, Jan Dubois <[EMAIL PROTECTED]> wrote:
> > > > PS: Please let me know if you happen to know a mechanism to create a
> > > > message-only window on 98/NT (a window that is not top-level and
> > > > will not receive broadcast messages). If this were possible,
> > > > then we could get rid of PostThreadMessage() completely.
> > >
> > > I can't speak for WinNT, as I don't have it available, but on Win98,
> > > using HWD_MESSAGE as the parent window to CreateWindowEx() appears to
> > > work fine (despite what MSDN says). Using it I end up with a window
> > > that is a child of a hidden system window. The window is not top
> > > level, not visible, and I can't make it receive a broadcast message.
> >
> > I've seen at least anecdotal evidence that using HWND_MESSAGE on 98
> might
> > be somewhat dangerous:
> >
> > http://www.virtualdub.org/blog/pivot/entry.php?id=153
> >
> > So I'm not sure if we want to ignore MSDN on this point.
>
> Thanks for that link. I had already readr it, and can confirm that
> GetAncestor(hwnd, GA_ROOT) crashes applications on my Win98 box. I'm
> nott 100% sure, what the reference to DialogBoxParam is, but if we
> assume that he was passing the message window handle as the owner
> window for a dialog, then it's well documented that this first thing
> the DialogBox...() functions do is call GetAncestor(..., GA_ROOT), to
> account for people passing a child window handle, which is not a valid
> owner-window. As we aren't likely to ever call GetAncestor() or
> DialogBox...() on the window, we might be safe. I'm less happy about
> what he says about the BSOD.
>
> There's surprisingly little information on on the web regarding
> HWND_MESSAGE. I think the safest bet is to keep using thread messages
> for the earlier systems. It's a shame, as loosing that complexity
> would have been good.
>
> Regards,
> Rob.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 30 Jul 2007 22:18:59 +0100
> From: "Robert May" <[EMAIL PROTECTED]>
> Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
> To: perl-win32-gui-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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]
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: win32.c.patch
> Type: application/octet-stream
> Size: 12021 bytes
> Desc: not available
>
> ------------------------------
>
> -------------------------------------------------------------------------
> 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/
>
>
> End of Perl-Win32-GUI-Users Digest, Vol 14, Issue 9
> ***************************************************
>
--
http://mail.google.com/mail/photos/static/UykTcFMUSSZlBPRqPNyMUKmXZaO60lDRgzMreAsYBtU10leFylauhTXh6Tlxc-MA
-------------------------------------------------------------------------
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/
