I have fixed the following bugs:
 
1. Rehashed the way Win32::GUI::Class constructor detects xp or not. Removed the whole ELSE condition of that part that checks the OS version; it's not needed since if -color is not set, it's set to the correct color later on in the constructor.
 
2. I was wrong about this one, I think.
 
3. Timers don't work with NEM. I fixed it like so: You add timers as normal, but also create add an onTimer option to your window. When a timer triggers, onTimer is called with the string argument of the timer that triggered. Had to define a new NEM event in GUI.h to support this:
 
#define PERLWIN32GUI_NEM_TIMER    0x08000000
 
4. Looked into this, and made one change: DoEvent_NEM was always returning -2 (saying it hadnt handled the event) when it should have returned 0. Now if it finds an appropriate event, it sets perlresult to default to 0. Perlresult can still be overridden by an error or something after this setting.
 
5. Exactly.
 
My bugfixed version is available here: http://baxpace.com/Win32-GUI-Fix.zip
 
The changes are scattered everywhere. If you have some kind of patch-generating program, that'd be a good idea. Patch relative to current CVS.
 
Steve
 
----- Original Message -----
From: Laurent ROCHER
To: Win32 GUI Hackers
Sent: Tuesday, December 02, 2003 9:00 PM
Subject: Re: [perl-win32-gui-hackers] CVS Commit

Hi,
 
 
1.
   
    Aldo make a change in GUI.pm for correct XP color but don't work for me on Win98Se.
 
In Win32::GUI::Class new
 
 # figure out the correct background color
 # (to avoid the "white background" syndrome on XP)
 if(not exists $args{-color}) {
  my($undef, $major, $minor) = Win32::GetOSVersion();
  if($major == 5 && $minor > 0) {   
   $args{-color} = Win32::GUI::constant("COLOR_BTNFACE", 0)+1;
  } else {
   $args{-color} = Win32::GUI::constant("COLOR_WINDOW", 0)+1;
  }
 }
 
    I remove red +1 and now it's correct for me.
 
2. 3. 4.
    New bug to investigate ;o)
 
5.
    If -style need to be deprecated, i don't think it's a good idea to a add -forcestyle.
    We keep -style without deprecated warning message.
    Or, we remove it and force people to use registered class for fix a default style.
 
    For me, -style don't need to be deprecated.
    It's a programmer choice (and supposed know what he's doing ;o).
    -popstyle/-pushstyle for set/reset a specific control style.
    -style are usefull for set a fixed style. 
 
Laurent.
----- Original Message -----

Hello.
 
I'm going to look into this list of bugs to see what I can fix, but I'm quite sure none of them are to do with my patches :) and maybe you have some answers:
 
1. Default DialogBox background is white on Windows 2000, rather than the correct colour for a buttonface/3dface. I assume this is known because it's blatantly obvious.
 
2. NEM event onResize seems to be called in the constructor for Windows and possibly all other widgets. This is very frustrating because if you use onResize to handle your scaling, then often it tries to scale widgets that have not yet been defined, causing an error.
 
3. Timers no longer seem to work as documented. In fact they don't work at all (for me). This could be something that only manifests itself when the NEM is used, but I haven't tested that.
 
4. NEM events seem to be triggered tons of times. For example when I click a mouse button I get about 60 onMouseDown calls.
 
5. There are times when -style is appropriate. I admit that -style SHOULD be deprecated, but there should be a new argument such as -forcestyle for when you know what you're doing. I can see that default styles could be changed in future, and hardcoding -popstyle for each default style seems rather crude to me.
 
Steve