perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Steve P. <st...@ba...>]

Hi,

I tried this, it doesnt solve my particular problem at all, in fact it
doesn't make the slightest difference. My window has a *lot* of widgets
(it's a whole application made in The GUI Loft with several panes), so the
flicker is probably very noticeable for me. Also, if you have a flatscreen
monitor (LCD) the flicker is much less noticeable.

Steve

----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Steve Pick" <st...@ba...>
Cc: "Win32 GUI Hackers" <per...@li...>
Sent: Sunday, December 14, 2003 6:36 PM
Subject: Re: [perl-win32-gui-hackers] Success with flicker-free windows!


> Hi,
>
>     Garside Trevor say on win32::GUI Users list flicker problem when
resize
> window can be remove by set default class style to 0.
>
>     In GUI.xs, RegisterClassEx :
>         wcx.style = 0; // CS_HREDRAW | CS_VREDRAW; // TODO (default class
> style...)
>
>     It's look better when resize main window.
>     I don't have samples whith lot of flicker problem.
>     So, don't know if it's sufficient.
>
> Laurent.
>
> > > > 4.    Graphics objects no longer show up (DCs don't seem to support
> > > > WM_PRINT).
> > > >
> > > > 5.    Setting WS_CLIPCHILDREN results in massive flickering (the
> > opposite of
> > > > what it used to do) and causes no background to show.
> > >
> > > Well, I don't really understand a lot of what you said, and I don't
have
> > > any applications that flicker with the current GUI, so I guess I'd
have
> > > to say that if *anything* gets "broken" by this "enhancement", that it
> > > should definitely be an "extra cost option", rather than the default.
> >
> > All my application widgets flickered when I resized the windows,
> especially
> > tree and listviews. This fix prevents the erase->redraw mentality of
> > Windows, which is a stupid way of doing things in the 1st place. It
would
> be
> > easy to add an option "-noflicker" to all windows so that you can
> explicitly
> > say "I want to use the non-flicker drawing routines". I will do this.
> >
>
>

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Jeremy W. <jez...@ho...>]

Humm - for some reason I'm not getting all messages to this list - anyone 
else have that problem? The archive is also not up to date...

I missed the start of the thread - Anyway my 2 cents....

>     Garside Trevor say on win32::GUI Users list flicker problem when 
>resize
>window can be remove by set default class style to 0.
>
>     In GUI.xs, RegisterClassEx :
>         wcx.style = 0; // CS_HREDRAW | CS_VREDRAW; // TODO (default class
>style...)
>
>     It's look better when resize main window.
>     I don't have samples whith lot of flicker problem.
>     So, don't know if it's sufficient.

This is the 'fix' that I have been using for a while, and works well in most 
simple cases. However you can get horrendous striping when reducing the size 
of a window - the GUI Loft being one example. In my case I had one window 
which suffered this problem, I just had to create a class with  CS_HREDRAW | 
CS_VREDRAW and suffer the flickering.

> > > > 4.    Graphics objects no longer show up (DCs don't seem to support
> > > > WM_PRINT).
> > > >
> > > > 5.    Setting WS_CLIPCHILDREN results in massive flickering (the
> > opposite of
> > > > what it used to do) and causes no background to show.
> > >
> > > Well, I don't really understand a lot of what you said, and I don't 
>have
> > > any applications that flicker with the current GUI, so I guess I'd 
>have
> > > to say that if *anything* gets "broken" by this "enhancement", that it
> > > should definitely be an "extra cost option", rather than the default.
> >
> > All my application widgets flickered when I resized the windows,
>especially
> > tree and listviews. This fix prevents the erase->redraw mentality of
> > Windows, which is a stupid way of doing things in the 1st place. It 
>would
>be
> > easy to add an option "-noflicker" to all windows so that you can
>explicitly
> > say "I want to use the non-flicker drawing routines". I will do this.

I like the idea of the "-noflicker" option (assuming you can turn it on and 
off during runtime). If it works with no cost, then perhaps it could become 
the default in future versions? Flicker free resizes are so *much* better.

Looking forward to seeing this fix in action.

Cheers.

jez.

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Laurent R. <ro...@cl...>]

Hi,

    Garside Trevor say on win32::GUI Users list flicker problem when resize
window can be remove by set default class style to 0.

    In GUI.xs, RegisterClassEx :
        wcx.style = 0; // CS_HREDRAW | CS_VREDRAW; // TODO (default class
style...)

    It's look better when resize main window.
    I don't have samples whith lot of flicker problem.
    So, don't know if it's sufficient.

Laurent.

> > > 4.    Graphics objects no longer show up (DCs don't seem to support
> > > WM_PRINT).
> > >
> > > 5.    Setting WS_CLIPCHILDREN results in massive flickering (the
> opposite of
> > > what it used to do) and causes no background to show.
> >
> > Well, I don't really understand a lot of what you said, and I don't have
> > any applications that flicker with the current GUI, so I guess I'd have
> > to say that if *anything* gets "broken" by this "enhancement", that it
> > should definitely be an "extra cost option", rather than the default.
>
> All my application widgets flickered when I resized the windows,
especially
> tree and listviews. This fix prevents the erase->redraw mentality of
> Windows, which is a stupid way of doing things in the 1st place. It would
be
> easy to add an option "-noflicker" to all windows so that you can
explicitly
> say "I want to use the non-flicker drawing routines". I will do this.
>

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Reini U. <ru...@x-...>]

Steve Pick schrieb:
> All my application widgets flickered when I resized the windows, especially
> tree and listviews. This fix prevents the erase->redraw mentality of
> Windows, which is a stupid way of doing things in the 1st place. It would be
> easy to add an option "-noflicker" to all windows so that you can explicitly
> say "I want to use the non-flicker drawing routines". I will do this.

Thanks, good idea.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Steve P. <st...@ba...>]

Hi,

> > 4.    Graphics objects no longer show up (DCs don't seem to support
> > WM_PRINT).
> >
> > 5.    Setting WS_CLIPCHILDREN results in massive flickering (the
opposite of
> > what it used to do) and causes no background to show.
>
> Well, I don't really understand a lot of what you said, and I don't have
> any applications that flicker with the current GUI, so I guess I'd have
> to say that if *anything* gets "broken" by this "enhancement", that it
> should definitely be an "extra cost option", rather than the default.

All my application widgets flickered when I resized the windows, especially
tree and listviews. This fix prevents the erase->redraw mentality of
Windows, which is a stupid way of doing things in the 1st place. It would be
easy to add an option "-noflicker" to all windows so that you can explicitly
say "I want to use the non-flicker drawing routines". I will do this.

Steve

Re: [perl-win32-gui-hackers] Success with flicker-free windows!

[Glenn L. <pe...@ne...>]

On approximately 12/13/2003 7:41 PM, came the following characters from
the keyboard of Steve Pick:
> Hi,
> 
> Yep I've done it. But my implementation SUCKS and breaks a few things so I
> won't commit yet.

> 4.    Graphics objects no longer show up (DCs don't seem to support
> WM_PRINT).
> 
> 5.    Setting WS_CLIPCHILDREN results in massive flickering (the opposite of
> what it used to do) and causes no background to show.

Well, I don't really understand a lot of what you said, and I don't have 
any applications that flicker with the current GUI, so I guess I'd have 
to say that if *anything* gets "broken" by this "enhancement", that it 
should definitely be an "extra cost option", rather than the default.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

[perl-win32-gui-hackers] Success with flicker-free windows!

[Steve P. <st...@ba...>]

Hi,

Yep I've done it. But my implementation SUCKS and breaks a few things so I
won't commit yet.

First, the HOW:

Before you read on, be prepared for nastiness.

When WM_ERASEBKGND is received in CommonMsgLoop it is discarded (so we stop
backround erasing happening).

When WM_PAINT is received in CommonMsgLoop a compatible DC and bitmap for
the window is created, and the DC handle is then sent back to the window in
a WM_PRINT message for drawing (WM_PRINT can be sent to make the window do
it's drawing in another DC). Now the DC that's just been WM_PRINTed on is
blitted back onto the window's DC.

Here are the problems:
1.    WM_PRINTCLIENT didn't do what I wanted (I expected it would draw
everything in the client area on a bitmap the size of the client area, but
this didn't want to work) so I had to use WM_PRINT, and do some sums to
calculate how to crop the resultant bitmap, which included blank areas for
the non-client-area.

2.    It's kind of slow. This is probably because it has to create a DC and
bitmap every time a WM_PAINT occurs, and it has to draw the whole window
(which it was doing anyway). It also does FillRect to clear the background
of the new bitmap to the right colour, and I couldnt find a faster way of
doing it than this.

3.    It fills the background of the new DC with the colour for
COLOR_BTNFACE, whatever your OS. This probably looks right on XP too, I
haven't tested it. I tried to use the color set in the window's class using
GetClassLong(hwnd,GCL_HBRBACKGROUND), but this always just returned "5"
rather than a brush handle, which is odd. Incidentally, 5 is the value of
COLOR_WINDOW, which Win32::GUI chooses as the class color on a win2k machine
(like mine) - could this point to a more elegant way of fixing the WinXP
white-background bug, I.e. the class color should be a brush rather than a
color?.

4.    Graphics objects no longer show up (DCs don't seem to support
WM_PRINT).

5.    Setting WS_CLIPCHILDREN results in massive flickering (the opposite of
what it used to do) and causes no background to show.

Despite these 5 points, on my machine it's not NOTICEABLY slow and my GUIs
feel so much more solid with it. Perhaps this feature should be optional?

No commit until I have some of your advice, questions or suggestions.

Steve

[perl-win32-gui-hackers] bugfixed some cvs

[Steve P. <st...@ba...>]

Hi,

Just fixed a bug with windows that had the -parent option given, and were
then positioned with the Left() and Top() methods. These methods were
detecting that the window had a parent and were translating X (in the case
of Top() ) and Y (in the case of Left() ) into the current X or Y
co-ordinate minus the parent X or Y co-ordinate, causing child windows that
were sent multiple Top(somenumber) or Left(somenumber) calls to "walk"
horizontally or vertically across the desktop in steps dependent on the
position of their parent window. Nasty.

You might be confused as to why I fixed this in quite the way I did (setting
a flag in userdata if the user specifies -parent).

I did this because I wanted to preserve the ability to explicitly call
SetParent on a window to insert it into another window's client area. This
is an especially handy trick for making hidable/moveable panes without
moving all the widgets one by one. If I simply detected if the thing that
was having Top/Left set was a window or not, it would not translate the
co-ordinates when it should do.

Anyway, I think I fixed this right. I'm tired, and a little confused now.
But the fix works and I've checked it for problems. It's in 665, is that
where I'm supposed to commit to still?

Steve

Re: [perl-win32-gui-hackers] CVS Commit -> Win32-GUI-0_0_667

[Glenn L. <pe...@ne...>]

On approximately 12/12/2003 10:44 AM, came the following characters from
the keyboard of Laurent ROCHER:

> I tag current 665-Fix CVS as Win32-GUI-0_0_670.
> I build PPM for 5.005, 5.6 and 5.8, and a source zip files.
> I include html in PPM archive (regenerate html from GUI source).
> 
> I have upload all on my web site and ppm repository.
> See : http://perso.club-internet.fr/rocherl/Win32GUI.html
> 
> Now, i'm try to see how put on sourceforge (except for 5.8).

Thanks Laurent, for all your hard work on this, not just the recent 
packaging, but also your debugging skills and your willingness to 
understand the submitted patches and improve them, rather than blindly 
applying them.

I grabbed the 5.8 0.0.670 package from your respository, and also got 
the notification from SourceForge about the new version, and grabbed the 
source from there for variety.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [perl-win32-gui-hackers] CVS Commit -> Win32-GUI-0_0_667

[Laurent R. <ro...@cl...>]

Hi,

> Do you mean that you don't have the rights to create a new package name?

I think only administrator can create new donwload package name.
I think i have only right to upload release file on existing package name.
Never try before.

> Is that something that only Aldo can do?  Maybe Aldo will do it for us
then?
>
> If not, I would be glad to host the PPM for the package briefly on my
> web site until we can make a more official home for it.

I tag current 665-Fix CVS as Win32-GUI-0_0_670.
I build PPM for 5.005, 5.6 and 5.8, and a source zip files.
I include html in PPM archive (regenerate html from GUI source).

I have upload all on my web site and ppm repository.
See : http://perso.club-internet.fr/rocherl/Win32GUI.html

Now, i'm try to see how put on sourceforge (except for 5.8).

> Is the issue that sourceforge hasn't had a package for Perl 5.8 prior to
now?

Yes ;o)

Laurent

Re: [perl-win32-gui-hackers] CVS Commit

[Glenn L. <pe...@ne...>]

Laurent,

Do you mean that you don't have the rights to create a new package name?

Is that something that only Aldo can do?  Maybe Aldo will do it for us then?

If not, I would be glad to host the PPM for the package briefly on my 
web site until we can make a more official home for it.

Is the issue that sourceforge hasn't had a package for Perl 5.8 prior to 
  now?


On approximately 12/11/2003 12:33 PM, came the following characters from
the keyboard of Laurent ROCHER:
> I commit :
> 
>     [Laurent Rocher]
>     - GUI.pm : Change version to 0.0.670
>     - GUI.h  : Set NO_XSLOCKS for perl 5.005
>     - GUI_MessageLoops.cpp : Fix for perl 5.005
> 
> Now Win32::GUI work for ActivePerl 5.005
> 
>     Does someone have something to add on CVS ?
> 
>     Where upload new package release ?
> 
>     We can put on Sourceforge but we need a new package name
> (Win32-GUI-PPM-5.8).
>     I can upload new release but not create new package name.
> 
> Laurent.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

[perl-win32-gui-hackers] CVS Commit

[Laurent R. <ro...@cl...>]

I commit :

    [Laurent Rocher]
    - GUI.pm : Change version to 0.0.670
    - GUI.h  : Set NO_XSLOCKS for perl 5.005
    - GUI_MessageLoops.cpp : Fix for perl 5.005

Now Win32::GUI work for ActivePerl 5.005

    Does someone have something to add on CVS ?

    Where upload new package release ?

    We can put on Sourceforge but we need a new package name
(Win32-GUI-PPM-5.8).
    I can upload new release but not create new package name.

Laurent.

[perl-win32-gui-hackers] Mini update to Hook()

[Stephen P. <Ste...@uc...>]

Hi,

Just thought I'd add a little something to the HEM =
(Hacker/Horrible/Hotchpotch Event Model). $win->Hook() now returns the =
previous coderef if you reassign a hook. For instance:

my $hookone =3D $win->Hook(0x0020, \&setcursor);
my $hooktwo =3D $win->Hook(0x0020, \&somethingelse);

$hookone now equals 0 (no previous reference).
$hooktwo is now a reference to &setcursor (the hook handler that was =
replaced by \&somethingelse).

You can't assign more than one handler to a message, since the message =
identifies the handler to call on a key/value basis (just a perl list).

The function still returns undef if you passed it invalid arguments, so =
error handling is a breeze:

if( defined($hookone) ) {
	if( ref($hookone) ) {
		print "Previous reference re-defined\n";
	}
	else {
		print "This is the first hook we've made for this message\n";
	}
}
else {
	print "We passed dumb arguments.\n";
}

It's in the CVS now. Hopefully this will make things more useful, and =
allows you to create modules that "grab" hooks but still honour any =
hooks that the user of your module has previously defined.

Steve

Re: [perl-win32-gui-hackers] DoEvents() bug -> CVS.

[Glenn L. <pe...@ne...>]

On approximately 12/10/2003 2:28 PM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi,
> 
> I commit DoEvents and some little change :
>     - GUI.pm : Add AddDatetime, AddGraphics methods
>     - GUI.xs : Fix DoEvents double event, add some DateTime methods
> (GetTime, SetTime, SetNone, IsNone).
>     - GUI_Options.cpp : Add option parsing for DateTime control
> (-align, -format, -shownone, -updown)
>     - Typemap : LPARAM handle as string or integer.
> 
> 
>>I still had a test case, and this DOES solve the keyboard entry jitter
>>problem.  Laurent, if this also cures Steve's mouse down problem, I
>>think it is time to make an official distribution.  We've fixed a number
>>of significant bugs and missing features, of which this is the most
>>significant.  So we should make it possible for people to use these
>>fixes easily, and put out a new version of Win32::GUI.
>>
>>I guess the biggest issue is what version number to give it, but Aldo
>>said his next version would be 1.xxx, so any old 0.0.VVV  for VVV > 665
>>would work to allow people to upgrade.
> 
> 
>     Yes, it's probably time for a new release.
>     I think 0.0.670 sound good.
> 
>     I can build PPM for 56 and 58.
>     But, i have trouble for build for 5.005, link fail.
>     I have message like this for all obj file.
> 
> GUI_Constants.obj : error LNK2005: "class CPerlObj *  pPerl"
> (?pPerl@@3PAVCPerlObj@@A) already defined in GUI.obj
> GUI_Constants.obj : error LNK2005: "class XSLockManager  g_XSLock"
> (?g_XSLock@@3VXSLockManager@@A) already defined in GUI.obj
> 
>     I had this in gui.h before perl.h and change some CPerl declaration.
> #if defined(PERL_OBJECT)
> #define NO_XSLOCKS
> #endif
>     Don't know exactly if it's good.
>     It's seem to work but i need do more test.
> 
> Laurent.

Did Win32::GUI ever work on 5.005 ?  I certainly wouldn't worry too much 
about supporting such an old release at this point.  5.6 and 5.8 seem 
sufficient to me.  But if you can figure out, without delaying things 
too much, more power to you.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [perl-win32-gui-hackers] DoEvents() bug -> CVS.

[Steve P. <st...@ba...>]

Bah, 5.005 is deprecated anyway in my book :/ You can't download it from
ActiveState anymore and i doubt anyone should be using it. So long as
there's a 5.6 and 5.8 release I think/assume most people will be happy.

Steve

----- Original Message ----- 
From: "Laurent ROCHER" <ro...@cl...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Wednesday, December 10, 2003 10:28 PM
Subject: Re: [perl-win32-gui-hackers] DoEvents() bug -> CVS.


> Hi,
>
> I commit DoEvents and some little change :
>     - GUI.pm : Add AddDatetime, AddGraphics methods
>     - GUI.xs : Fix DoEvents double event, add some DateTime methods
> (GetTime, SetTime, SetNone, IsNone).
>     - GUI_Options.cpp : Add option parsing for DateTime control
> (-align, -format, -shownone, -updown)
>     - Typemap : LPARAM handle as string or integer.
>
> > I still had a test case, and this DOES solve the keyboard entry jitter
> > problem.  Laurent, if this also cures Steve's mouse down problem, I
> > think it is time to make an official distribution.  We've fixed a number
> > of significant bugs and missing features, of which this is the most
> > significant.  So we should make it possible for people to use these
> > fixes easily, and put out a new version of Win32::GUI.
> >
> > I guess the biggest issue is what version number to give it, but Aldo
> > said his next version would be 1.xxx, so any old 0.0.VVV  for VVV > 665
> > would work to allow people to upgrade.
>
>     Yes, it's probably time for a new release.
>     I think 0.0.670 sound good.
>
>     I can build PPM for 56 and 58.
>     But, i have trouble for build for 5.005, link fail.
>     I have message like this for all obj file.
>
> GUI_Constants.obj : error LNK2005: "class CPerlObj *  pPerl"
> (?pPerl@@3PAVCPerlObj@@A) already defined in GUI.obj
> GUI_Constants.obj : error LNK2005: "class XSLockManager  g_XSLock"
> (?g_XSLock@@3VXSLockManager@@A) already defined in GUI.obj
>
>     I had this in gui.h before perl.h and change some CPerl declaration.
> #if defined(PERL_OBJECT)
> #define NO_XSLOCKS
> #endif
>     Don't know exactly if it's good.
>     It's seem to work but i need do more test.
>
> Laurent.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>

Re: [perl-win32-gui-hackers] DoEvents() bug -> CVS.

[Laurent R. <ro...@cl...>]

Hi,

I commit DoEvents and some little change :
    - GUI.pm : Add AddDatetime, AddGraphics methods
    - GUI.xs : Fix DoEvents double event, add some DateTime methods
(GetTime, SetTime, SetNone, IsNone).
    - GUI_Options.cpp : Add option parsing for DateTime control
(-align, -format, -shownone, -updown)
    - Typemap : LPARAM handle as string or integer.

> I still had a test case, and this DOES solve the keyboard entry jitter
> problem.  Laurent, if this also cures Steve's mouse down problem, I
> think it is time to make an official distribution.  We've fixed a number
> of significant bugs and missing features, of which this is the most
> significant.  So we should make it possible for people to use these
> fixes easily, and put out a new version of Win32::GUI.
>
> I guess the biggest issue is what version number to give it, but Aldo
> said his next version would be 1.xxx, so any old 0.0.VVV  for VVV > 665
> would work to allow people to upgrade.

    Yes, it's probably time for a new release.
    I think 0.0.670 sound good.

    I can build PPM for 56 and 58.
    But, i have trouble for build for 5.005, link fail.
    I have message like this for all obj file.

GUI_Constants.obj : error LNK2005: "class CPerlObj *  pPerl"
(?pPerl@@3PAVCPerlObj@@A) already defined in GUI.obj
GUI_Constants.obj : error LNK2005: "class XSLockManager  g_XSLock"
(?g_XSLock@@3VXSLockManager@@A) already defined in GUI.obj

    I had this in gui.h before perl.h and change some CPerl declaration.
#if defined(PERL_OBJECT)
#define NO_XSLOCKS
#endif
    Don't know exactly if it's good.
    It's seem to work but i need do more test.

Laurent.

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Glenn L. <pe...@ne...>]

YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES
YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU

I still had a test case, and this DOES solve the keyboard entry jitter
problem.  Laurent, if this also cures Steve's mouse down problem, I 
think it is time to make an official distribution.  We've fixed a number 
of significant bugs and missing features, of which this is the most 
significant.  So we should make it possible for people to use these 
fixes easily, and put out a new version of Win32::GUI.

I guess the biggest issue is what version number to give it, but Aldo 
said his next version would be 1.xxx, so any old 0.0.VVV  for VVV > 665 
would work to allow people to upgrade.


On approximately 12/10/2003 11:32 AM, came the following characters from
the keyboard of Laurent ROCHER:

>>Glenn Linderman wrote:
>>
>>>But I think if you use Win32::API to call call PeekMessage with the
>>>PM_REMOVE set, that you may not get the repeated behavior... me thinks
>>>the bug is inside DoEvents, somehow.... it just hit me... maybe the
>>>PM_REMOVE constant is wrong?  (Pure speculation here, but something is
>>>wrong, and it isn't obvious.)
>>
>>no, the PM_REMOVE seems to be correct. I also tried to debug this one
>>really hard, to no avail.
>>
> 
> 
>     I think problem come from use of PeekMessage return value.
> 
>     PeekMessage Return Values:
>     If a message is available, the return value is nonzero.
>     If no messages are available, the return value is zero.
> 
>     In current DoEvents code, when PeekMessage return 0, loop exit only
> after proceding last MSG.
> 
>    while(stayhere) {
>         stayhere = PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
> #ifdef PERLWIN32GUI_STRONGDEBUG
>         printf("XS(DoEvents): PeekMessage returned %d\n", stayhere);
> #endif
>         if(msg.message == WM_EXITLOOP) {
>             stayhere = 0;
>             msg.wParam = (WPARAM) -1;
>         } else {
>             if(stayhere == -1) {
>                 stayhere = 0;
>                 msg.wParam = (WPARAM) -2; // an error occurred...
>             }
>             else {
>                 ...
>             }
>         }
>     }
> 
>     I think code below resolve double event call.
> 
> Laurent
> 
> 
> ###########################################################################
>     # (@)METHOD:DoEvents()
> DWORD
> DoEvents(hwnd=NULL)
>     HWND hwnd
> PREINIT:
>     MSG msg;
>     HWND phwnd;
>     HWND thwnd;
>     int stayhere;
>     BOOL fIsDialog;
>     HACCEL acc;
>     LPPERLWIN32GUI_USERDATA perlud;
> CODE:
>     stayhere = 1;
>     fIsDialog = FALSE;
>     while(stayhere) {
>         stayhere = PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
> #ifdef PERLWIN32GUI_STRONGDEBUG
>         printf("XS(DoEvents): PeekMessage returned %d\n", stayhere);
> #endif
>         if (stayhere) {
>             if(msg.message == WM_EXITLOOP) {
>                 stayhere = 0;
>                 msg.wParam = (WPARAM) -1;
>             } else  {
>                 // #### trace back to the window's parent
>                 phwnd = msg.hwnd;
>                 while(thwnd = GetParent(phwnd)) {
>                     phwnd = thwnd;
>                 }
>                 // #### now see if the parent window is a DialogBox
>                 fIsDialog = FALSE;
>                 acc = NULL;
>                 perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong(phwnd,
> GWL_USERDATA);
>                 if( ValidUserData(perlud) ) {
>                     fIsDialog = perlud->dwPlStyle & PERLWIN32GUI_DIALOGUI;
>                     acc = perlud->hAcc;
>                 }
> 
>                 if(acc && TranslateAccelerator(phwnd, acc, &msg))
>                     continue;
> 
>                 if(fIsDialog && IsDialogMessage(phwnd, &msg))
>                     continue;
> 
>                 TranslateMessage(&msg);
>                 DispatchMessage(&msg);
>             }
>         }
>         else
>             msg.wParam = (WPARAM) 0;
>     }
>     RETVAL = msg.wParam;
> OUTPUT:
>     RETVAL
> 
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [perl-win32-gui-hackers] "Fix": DoEvents() bug.

[Glenn L. <pe...@ne...>]

On approximately 12/10/2003 5:45 AM, came the following characters from
the keyboard of Stephen Pick:

> Hi.
> 
> OK. This is probably the strangest and most baffling fix I could have
> stumbled on for this bug but here goes:
> 
> IO flushing.
> 
> Yep. If you flush *any* filehandle currently open for writing (by
> whatever means you like) immediately after calling Win32::GUI::DoEvents,
> you don't get repeated messages. Flushing in the actual DoEvents C code
> doesnt work, the flush must be done in Perl, and outside of any event
> handler. You can even flush a filehandle you just open()ed for writing.
> Don't ask me.
> 
> This works (uses IO::Handle to flush stdout):
> 
> use IO::Handle;
> my $io = new_from_fd IO::Handle(1,">");
> while(1) {
> 	Win32::GUI::DoEvents;
> 	$io->flush();
> }
> 
> As does this (uses print to flush):
> 
> while(1) {
> 	Win32::GUI::DoEvents;
> 	print "\n";
> }
> 
> And this (uses print and autoflush to prevent filling the console with
> emptiness):
> 
> $| = 1;
> while(1) {
> 	Win32::GUI::DoEvents;
> 	print " \010";
> }
> 
> Now if anyone can explain away THIS behaviour I'll be really impressed.

So will I !!!!  But at least we now have a clue of sorts.

> I did try to dig through perl's internals to find out exactly WHAT it
> does on flush (I suspect it's slightly more than just an fflush() ).
> Could this possibly be anything to do with the "<DATA> line xxx" i see
> in every console warning message created by Win32::GUI ?? What *is* that
> all about?

What THAT is all about is a missing close in Win32::API::Type.pm ....

Here's the text of the message I sent to Aldo on 11/21/2003 when I 
discovered the problem:  Sorry about the formatting below.

> Hi Aldo,
> 
> In the file Win32/API/Type.pm the INIT section fails to close the DATA handle, causing all error messages in scripts that "use Win32::API" to have an extra "<DATA> line 164" at the end of the location reference.
> 
> This is confusing, because people don't expect modules to leave files open during a use, and especially if they have a data section of their own that they didn't think they'd opened yet.... or thought they had closed already...
> 
> A line containing
> 
> close( DATA );
> 
> just before the last } of the INIT section in that file seems to cure the problem. 

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Laurent R. <ro...@cl...>]

> Glenn Linderman wrote:
> > But I think if you use Win32::API to call call PeekMessage with the
> > PM_REMOVE set, that you may not get the repeated behavior... me thinks
> > the bug is inside DoEvents, somehow.... it just hit me... maybe the
> > PM_REMOVE constant is wrong?  (Pure speculation here, but something is
> > wrong, and it isn't obvious.)
>
> no, the PM_REMOVE seems to be correct. I also tried to debug this one
> really hard, to no avail.
>

    I think problem come from use of PeekMessage return value.

    PeekMessage Return Values:
    If a message is available, the return value is nonzero.
    If no messages are available, the return value is zero.

    In current DoEvents code, when PeekMessage return 0, loop exit only
after proceding last MSG.

   while(stayhere) {
        stayhere = PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
#ifdef PERLWIN32GUI_STRONGDEBUG
        printf("XS(DoEvents): PeekMessage returned %d\n", stayhere);
#endif
        if(msg.message == WM_EXITLOOP) {
            stayhere = 0;
            msg.wParam = (WPARAM) -1;
        } else {
            if(stayhere == -1) {
                stayhere = 0;
                msg.wParam = (WPARAM) -2; // an error occurred...
            }
            else {
                ...
            }
        }
    }

    I think code below resolve double event call.

Laurent


###########################################################################
    # (@)METHOD:DoEvents()
DWORD
DoEvents(hwnd=NULL)
    HWND hwnd
PREINIT:
    MSG msg;
    HWND phwnd;
    HWND thwnd;
    int stayhere;
    BOOL fIsDialog;
    HACCEL acc;
    LPPERLWIN32GUI_USERDATA perlud;
CODE:
    stayhere = 1;
    fIsDialog = FALSE;
    while(stayhere) {
        stayhere = PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
#ifdef PERLWIN32GUI_STRONGDEBUG
        printf("XS(DoEvents): PeekMessage returned %d\n", stayhere);
#endif
        if (stayhere) {
            if(msg.message == WM_EXITLOOP) {
                stayhere = 0;
                msg.wParam = (WPARAM) -1;
            } else  {
                // #### trace back to the window's parent
                phwnd = msg.hwnd;
                while(thwnd = GetParent(phwnd)) {
                    phwnd = thwnd;
                }
                // #### now see if the parent window is a DialogBox
                fIsDialog = FALSE;
                acc = NULL;
                perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong(phwnd,
GWL_USERDATA);
                if( ValidUserData(perlud) ) {
                    fIsDialog = perlud->dwPlStyle & PERLWIN32GUI_DIALOGUI;
                    acc = perlud->hAcc;
                }

                if(acc && TranslateAccelerator(phwnd, acc, &msg))
                    continue;

                if(fIsDialog && IsDialogMessage(phwnd, &msg))
                    continue;

                TranslateMessage(&msg);
                DispatchMessage(&msg);
            }
        }
        else
            msg.wParam = (WPARAM) 0;
    }
    RETVAL = msg.wParam;
OUTPUT:
    RETVAL

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Glenn L. <pe...@ne...>]

On approximately 12/10/2003 8:53 AM, came the following characters from
the keyboard of Johan Lindstrom:

> At 17:38 2003-12-10, Aldo Calpini wrote:
> 
>> DoEvents is an important feature, and this bug should be solved. I've
>> read what Steve has found out (the flush thing) and I'm totally
>> puzzled. I will try to do some testing here to see if we can come up
>> with something.
> 
> 
> Just throwing out ideas:
> Could it be a timing issue, and any delay can reproduce this? Like e.g.
> 
> select(undef, undef, undef, 0.001);

I added big delays while debugging/tracing, and with a big enough delay, 
the keyboard repeat problem was less pronounced, but didn't completely 
go away.  I was using delays on the order of seconds, not milliseconds, 
by the way, so I don't think you'd see any difference with really small 
delays.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Johan L. <jo...@ba...>]

At 17:38 2003-12-10, Aldo Calpini wrote:
>DoEvents is an important feature, and this bug should be solved. I've
>read what Steve has found out (the flush thing) and I'm totally
>puzzled. I will try to do some testing here to see if we can come up
>with something.

Just throwing out ideas:
Could it be a timing issue, and any delay can reproduce this? Like e.g.

select(undef, undef, undef, 0.001);


/J

-------- ------ ---- --- -- --  --  -    -     -      -         -
Johan Lindström    Sourcerer @ Boss Casinos     jo...@ba...

Latest bookmark: "TinyPerl Project"
http://tinyperl.sourceforge.net/
dmoz (1 of 9): /Computers/Programming/Languages/Java/ 25

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Aldo C. <da...@pe...>]

Glenn Linderman wrote:
> But I think if you use Win32::API to call call PeekMessage with the
> PM_REMOVE set, that you may not get the repeated behavior... me thinks 
> the bug is inside DoEvents, somehow.... it just hit me... maybe the 
> PM_REMOVE constant is wrong?  (Pure speculation here, but something is 
> wrong, and it isn't obvious.)

no, the PM_REMOVE seems to be correct. I also tried to debug this one
really hard, to no avail.

> [...] This makes me think it might be some sort of reentrancy
> problem, or that I am very, very confused.  At this point, I'm open to 
> suggestions, and have given up on debugging that issue, but am avoiding 
> writing code that uses DoEvents until (1) I screw up my courage to dive 
> into debugging it having learned some new thing about Windows API (2) 
> someone else fixes it.

DoEvents is an important feature, and this bug should be solved. I've
read what Steve has found out (the flush thing) and I'm totally
puzzled. I will try to do some testing here to see if we can come up
with something.


cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl-win32-gui-hackers] DoEvents() bug.

[Glenn L. <pe...@ne...>]

On approximately 12/10/2003 2:44 AM, came the following characters from
the keyboard of Stephen Pick:
> Hi Glenn,
> 
> I admit I was looking at a slightly older version of the CVS (since I
> can't get access to CVS at work anymore), but most things are the same
> from what I checked at home.

OK, I figured you must be looking at an older version to notice the acc= 
difference.

> You mention that messages are queued and combined. 

I know that mouse movement operations are "combined", the Windows 
documention points out that recording a separate message for every pixel 
of motion would consume great length of queue, to little avail... if the 
program isn't watching the mouse cursor position for some particular 
reason, all it generally cares about is that it moved, and where it 
wound up.

> I'd not class myself
> as highly experienced with Windows messaging, but the PeekMessage call
> in DoEvents specifies "PM_REMOVE" to delete the message it captures from
> the queue, so this message should be removed. Are you saying that when
> one uses PeekMessage, WM_LBUTTONDOWN messages will be continually
> generated by windows, even if PM_REMOVE is specified?

I'm not saying that; I'm saying that I don't know the extent of the 
types of operations that Windows might decide to queue and combine; I 
wouldn't expect that mouse down would be combinable, but then again I 
wouldn't have expected that the IBM PC keyboard design would generate 
repeated Key Down messages for held keys, either.  Seems like one, when 
you actually push it down, would suffice, any actions that should result 
from holding it would seem to be possible to generate in software, not 
hardware.  But I think the hardware generates multiples.  I'm not at all 
sure what Windows does with them, but it seems that "programming the 
keyboard repeat rate" is still the way that Windows changes the repeat 
rate for keystrokes.  So whether either the "combined" queue effect, or 
the "key down repeat" technique is used for "mouse down" I have no clue. 
  But I thought I'd mention it, to get you thinking about broad 
possibilities of what you might not see in the code.

> The problem is that if GetMessage is called when the mouse button is
> down, the WM_LBUTTONDOWN message is received, and if you then call
> GetMessage again, no message is received. However if you call
> PeekMessage with PM_REMOVE set you get the WM_LBUTTONDOWN message, then
> if you call PeekMessage again with PM_REMOVE set, you get the
> WM_LBUTTONDOWN message a second time, then a third time, over and over
> *until another event occurs such as WM_PAINT or WM_MOUSEMOVE*.

But I think if you use Win32::API to call call PeekMessage with the 
PM_REMOVE set, that you may not get the repeated behavior... me thinks 
the bug is inside DoEvents, somehow.... it just hit me... maybe the 
PM_REMOVE constant is wrong?  (Pure speculation here, but something is 
wrong, and it isn't obvious.)

> There is a function (WaitForInputIdle)that "waits until the specified
> process is waiting for user input with no input pending, or until the
> time-out interval has elapsed" and a flag for PeekMessage (PM_NOYIELD)
> that "prevents the system from releasing any thread that is waiting for
> the caller to go idle"
> 
> Perhaps these might fix the problem?

I haven't noticed those before.  So much to learn about Windows API.

> I'm pretty sure that the textfield character-doubling could be to do
> with the fact that one gets both WM_KEYDOWN and WM_KEYUP messages when a
> key is pressed, and a character is produced for both for some reason. I
> will muck about with the CVS version (which I can now obtain at work
> thanks to my cute PC-Anywhere-Via-HTTP-Proxy thingy :) ) and see if I
> can find a way to solve the problem.

I wondered that myself, and convinced myself that no, that probably 
wasn't the case.   By tracing and monitoring messages received in 
DoEvents and Dialog, and tracing and monitoring the calls to 
DefWindowProc, and observing what happens in the textfield as I type, I 
have concluded that the Key Down message is received once, but the Key 
Up message is received and processed multiple times to contribute to the 
problem.  This makes me think it might be some sort of reentrancy 
problem, or that I am very, very confused.  At this point, I'm open to 
suggestions, and have given up on debugging that issue, but am avoiding 
writing code that uses DoEvents until (1) I screw up my courage to dive 
into debugging it having learned some new thing about Windows API (2) 
someone else fixes it.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.

[perl-win32-gui-hackers] "Fix": DoEvents() bug.

[Stephen P. <Ste...@uc...>]

Hi.

OK. This is probably the strangest and most baffling fix I could have
stumbled on for this bug but here goes:

IO flushing.

Yep. If you flush *any* filehandle currently open for writing (by
whatever means you like) immediately after calling Win32::GUI::DoEvents,
you don't get repeated messages. Flushing in the actual DoEvents C code
doesnt work, the flush must be done in Perl, and outside of any event
handler. You can even flush a filehandle you just open()ed for writing.
Don't ask me.

This works (uses IO::Handle to flush stdout):

use IO::Handle;
my $io =3D new_from_fd IO::Handle(1,">");
while(1) {
	Win32::GUI::DoEvents;
	$io->flush();
}

As does this (uses print to flush):

while(1) {
	Win32::GUI::DoEvents;
	print "\n";
}

And this (uses print and autoflush to prevent filling the console with
emptiness):

$| =3D 1;
while(1) {
	Win32::GUI::DoEvents;
	print " \010";
}

Now if anyone can explain away THIS behaviour I'll be really impressed.
I did try to dig through perl's internals to find out exactly WHAT it
does on flush (I suspect it's slightly more than just an fflush() ).
Could this possibly be anything to do with the "<DATA> line xxx" i see
in every console warning message created by Win32::GUI ?? What *is* that
all about?

Steve

RE: [perl-win32-gui-hackers] DoEvents() bug.

[Stephen P. <Ste...@uc...>]

Hi Glenn,

I admit I was looking at a slightly older version of the CVS (since I
can't get access to CVS at work anymore), but most things are the same
from what I checked at home.

You mention that messages are queued and combined. I'd not class myself
as highly experienced with Windows messaging, but the PeekMessage call
in DoEvents specifies "PM_REMOVE" to delete the message it captures from
the queue, so this message should be removed. Are you saying that when
one uses PeekMessage, WM_LBUTTONDOWN messages will be continually
generated by windows, even if PM_REMOVE is specified?

The problem is that if GetMessage is called when the mouse button is
down, the WM_LBUTTONDOWN message is received, and if you then call
GetMessage again, no message is received. However if you call
PeekMessage with PM_REMOVE set you get the WM_LBUTTONDOWN message, then
if you call PeekMessage again with PM_REMOVE set, you get the
WM_LBUTTONDOWN message a second time, then a third time, over and over
*until another event occurs such as WM_PAINT or WM_MOUSEMOVE*.

There is a function (WaitForInputIdle)that "waits until the specified
process is waiting for user input with no input pending, or until the
time-out interval has elapsed" and a flag for PeekMessage (PM_NOYIELD)
that "prevents the system from releasing any thread that is waiting for
the caller to go idle"

Perhaps these might fix the problem?

I'm pretty sure that the textfield character-doubling could be to do
with the fact that one gets both WM_KEYDOWN and WM_KEYUP messages when a
key is pressed, and a character is produced for both for some reason. I
will muck about with the CVS version (which I can now obtain at work
thanks to my cute PC-Anywhere-Via-HTTP-Proxy thingy :) ) and see if I
can find a way to solve the problem.

Steve

-----Original Message-----
From: Glenn Linderman [mailto:pe...@ne...]
Sent: 09 December 2003 19:03
To: Stephen Pick
Cc: Win32 GUI Hackers
Subject: Re: [perl-win32-gui-hackers] DoEvents() bug.


On approximately 12/9/2003 2:59 AM, came the following characters from
the keyboard of Stephen Pick:

> Hi all.
>=20
> When I do this:
>=20
> Win32::GUI::Dialog()
>=20
> I receive all my events like WM_LBUTTONDOWN (-onMouseDown) once, as
> should happen.
>=20
> When I do this:
>=20
> while(1) {
> 	Win32::GUI::DoEvents()
> 	print "Loop!\n";
> }
>=20
> I get endless calls to my event handler so long as the mouse button is
> down. I have NO idea why. Must be some kind of windows internal thing.

Certain Windows messages are "queued and combined" if you are not=20
looking, but the more often you look, the more often you get them....  I

could say if MouseDown is one of those, off hand.

I have noticed that a difference between Dialog() and DoEvents() is that

if used to process a dialog box containing a text box, that the former=20
responds normally, but the latter generally doubles the characters=20
received by the text box.  One difference in my situation is that I was=20
  calling DoEvents() from an event, and that might cause some sort of=20
reentrancy problem, but I couldn't understand what it would be if it is=20
such.  I gave up and restructured my code to use Dialog() only.

> Additionally, since the code for DoEvents() and Dialog() is
practically
> identical except that DoEvents uses PeekMessage and Dialog uses
> GetMessage, I copied both into seperate files and took a look at them
in
> WinMerge. Interesting. Dialog does ENTER; SAVETMPS; before doing
> GetMessage and FREETMPS; LEAVE; at the end of it's while() loop.
> DoEvents() doesn't do this.=20

This is because Dialog is "long-running" and needs to be sure to do Perl

temporary variable management, and DoEvents returns to Perl more often,=20
so can let Perl do the temporary variable management.  I think.

> Also, DoEvents has the line "acc =3D
> perlud->hAcc;", and Dialog() DOESNT have that. Dialog() does a
> comparison on acc (acc !=3D NULL) in the next few lines just like
DoEvents
> does, but this comparison will always yield false in Dialog().

I think that was one of the lines I "fixed" in making accelerator keys=20
work.  If not, it should have been.  What version of source are you=20
looking at?

> So. I don't have a compiler here but this is weird. Surely these
> functions should be identical but for the change from GetMessage to
> PeekMessage. Moreover, if these functions should be identical then why
> write the same code for both when a simple function that does either
> PeekMessage or GetMessage depending on an argument would remove a lot
of
> redundant code, for example the new function checkEvents(hwnd,
> peekmessage) would do the current Dialog() code with PeekMessage if
> peekmessage was set to 1, otherwise it'd do GetMessage, and the
Dialog()
> and DoEvents() methods could be truncated to:

Well, the exit condition is different too, not just the call to=20
GetMessage vs PeekMessage.  But that also could be based on the=20
"argument".  I agree there is much redundant code there, also see
DoModal.

>=20
> DWORD
> Dialog(hwnd=3DNULL)
> 	HWND hwnd
> CODE:
> 	RETVAL =3D checkEvents(hwnd,0);
> OUTPUT:
> 	RETVAL
>=20
> DWORD
> DoEvents(hwnd=3DNULL)
> 	HWND hwnd
> CODE:
> 	RETVAL =3D checkEvents(hwnd,1);
> OUTPUT:
> 	RETVAL
>=20
>=20
>=20
> Steve
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>=20
>=20

--=20
Glenn -- http://nevcal.com/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26

  billion on revenue of $2.81 billion.
  --from Reuters via=20
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more=20
investment in Windows technology, particularly in the area of=20
reliability, the profit percentage might go down, but so might the bugs=20
and security problems?  Seems like it would be a reasonable tradeoff.=20
WalMart earnings are 3.4% of investment.