2007/7/31, perl-win32-gui-users-request@lists.sourceforge.net < perl-win32-gui-users-request@lists.sourceforge.net>:
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
       perl-win32-gui-users-request@lists.sourceforge.net

You can reach the person managing the list at
       perl-win32-gui-users-owner@lists.sourceforge.net

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" <jand@activestate.com>
Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
To: "'Robert May'" < robertemay@users.sourceforge.net>
Cc: perl-win32-gui-users@lists.sourceforge.net
Message-ID: <051601c7d17c$68c63ac0$3a52b040$@com>
Content-Type: text/plain;       charset="us-ascii"

On Sat, 28 Jul 2007, Robert May wrote:
> On 28/07/07, Jan Dubois <jand@activestate.com> 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" < robertemay@users.sourceforge.net>
Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
To: "Jan Dubois" <jand@activestate.com>
Cc: perl-win32-gui-users@lists.sourceforge.net
Message-ID:
       <54bdc7510707290519w75be9f53g43ef04823c6bb1d4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 29/07/07, Jan Dubois <jand@activestate.com> wrote:
> On Sat, 28 Jul 2007, Robert May wrote:
> > On 28/07/07, Jan Dubois < jand@activestate.com> 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" <robertemay@users.sourceforge.net>
Subject: [perl-win32-gui-users] HWND_MESSAGE on Win98 [Was: Why is my
       GUI     hanging?]
To: "Jan Dubois" <jand@activestate.com>
Cc: perl-win32-gui-users@lists.sourceforge.net
Message-ID:
       <54bdc7510707290759i11e09fabx1f165af21cf8b3fd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 29/07/07, Jan Dubois <jand@activestate.com> 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" <jand@activestate.com>
Subject: Re: [perl-win32-gui-users] HWND_MESSAGE on Win98
To: "'Robert May'" < robertemay@users.sourceforge.net>
Cc: perl-win32-gui-users@lists.sourceforge.net
Message-ID: <05cf01c7d27d$a07d4e20$e177ea60$@com>
Content-Type: text/plain;       charset="us-ascii"

On Sun, 29 Jul 2007, Robert May wrote:
>  On 29/07/07, Jan Dubois <jand@activestate.com> 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" <robertemay@users.sourceforge.net >
Subject: Re: [perl-win32-gui-users] HWND_MESSAGE on Win98
To: "Jan Dubois" <jand@activestate.com>
Cc: perl-win32-gui-users@lists.sourceforge.net
Message-ID:
       <54bdc7510707301211q7021711ejf78c28d7ef71e07e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 30/07/07, Jan Dubois <jand@activestate.com> wrote:
> On Sun, 29 Jul 2007, Robert May wrote:
> >  On 29/07/07, Jan Dubois < jand@activestate.com> 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" <robertemay@users.sourceforge.net>
Subject: Re: [perl-win32-gui-users] Why is my GUI hanging?
To: perl-win32-gui-users@lists.sourceforge.net
Message-ID:
       <54bdc7510707301418t1c88c23au615719491f5bb5a8@mail.gmail.com>
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 < robertemay@users.sourceforge.net> wrote:
> > On 29/07/07, Jan Dubois <jand@activestate.com> 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 <robertemay@users.sourceforge.net> 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:
rob@themayfamily.me.uk
-------------- 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