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

Reply via email to