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

Re: [perl-win32-gui-hackers] Setting the background of a window - broken?

[Jez W. <je...@je...>]

Hi,

I was assuming that there was a way to change the background color of the=
=20
window during runtime? As for using a class, I had already tried that:

use Win32::GUI;
use strict;
my $WC =3D new Win32::GUI::Class(
    -name =3D> "Background",
   # -style =3D> 0,
    -background =3D> [208,187,255],
);

my $win =3D new Win32::GUI::Window (
    -pos         =3D> [100, 100],
    -size        =3D> [550, 235],
    -name        =3D> "Window",
    -text        =3D> "testing",
    -class       =3D> $WC,
);

$win->Show();

Win32::GUI::Dialog();

No joy - but running the FetchURL.pl example in loft did bring up a windo=
w=20
with a different window (then crashed on exit - that DC issue).

Cheers,

jez.
----- Original Message -----=20
From: "Johan Lindstrom" <jo...@Da...>
To: "guihackers" <per...@li...>
Sent: Tuesday, October 26, 2004 4:40 PM
Subject: Re: [perl-win32-gui-hackers] Setting the background of a window =
-=20
broken?


> At 17:26 2004-10-26, Jez White wrote:
>>For the life of me I can't seem to be able to set the background color =
of=20
>>a window - I know you could in previous versions.
>>
>>Surely -background =3D> [255,0,0] should work just like with controls?
>
> I don't think that ever worked, but I'm not sure. You need to create a=20
> Win32::GUI::Class and assign a background color to it and assign the cl=
ass=20
> to the window.
>
> There's a TGL demo program that does this.
>
>
> /J
>
> -------- ------ ---- --- -- --  --  -     -     -        -          -
> Johan Lindstr=F6m    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com
>
> Latest bookmark: "TCP Connection Passing"
> http://tcpcp.sourceforge.net/
> dmoz: /Computers/Programming/Languages/JavaScript/ 12
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJourna=
l
> Use IT products in your business? Tell us what you think of them. Give =
us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out=20
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers=20

Re: [perl-win32-gui-hackers] Setting the background of a window - broken?

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

At 17:26 2004-10-26, Jez White wrote:
>For the life of me I can't seem to be able to set the background color of 
>a window - I know you could in previous versions.
>
>Surely -background => [255,0,0] should work just like with controls?

I don't think that ever worked, but I'm not sure. You need to create a 
Win32::GUI::Class and assign a background color to it and assign the class 
to the window.

There's a TGL demo program that does this.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

[perl-win32-gui-hackers] Setting the background of a window - broken?

[Jez W. <je...@je...>]

Hi,

For the life of me I can't seem to be able to set the background color =
of a window - I know you could in previous versions.

Surely -background =3D> [255,0,0] should work just like with controls?

Cheers,

jez.

Re: [perl-win32-gui-hackers] noflicker, bitmaps, and painting the background, 0.99_1

[Jez W. <je...@je...>]

Hi,

I've had a little look at this - and I can reproduce your problem. I don't 
think this is a bug with win32::gui.

From memory the InvalidateRect did fix things, but I don't think the same 
approach would work for the current version of this example.

In a normal operation, InvalidateRect(1) would cause that window to be 
redrawn, with the whole background being painted first. In the samples case, 
we have set various options to stop the background being drawn (the 
clipchildren flags and the wc class), this stops the flicker but we have to 
manually repaint the background when required. When a smaller sized bitmap 
is opened, the BitBlt only paints the bitmap, even though it has been given 
coordinates to repaint the whole window. Somehow, the window will have to be 
manually cleared in those situations (using FillRect with the system 
brush?). I think that should fix things...

I think:)

Cheers,

jez.



----- Original Message ----- 
From: "Glenn Linderman" <pe...@ne...>
To: "Win32 GUI Hackers" <per...@li...>
Sent: Tuesday, October 26, 2004 4:45 AM
Subject: [perl-win32-gui-hackers] noflicker, bitmaps, and painting the 
background, 0.99_1


> Hi,
>
> So I have my application that borrows liberally from the sample code 
> BitmapScroll.pl.
>
> So in my application, I change the size of the bitmap I'm displaying, 
> within a window that sometimes can display the whole thing... and 
> sometimes has a right/bottom border of background around it.  (One might 
> consider centering the image in that case, but I haven't gotten that 
> far!).
>
> Anyway, I noticed a phenomenon:  When I switch from big bmp to little bmp, 
> the background doesn't get redrawn so portions of the bigger bitmap are 
> still visible.
>
> I recall that this was a problem with an early version of the sample, and 
> Jez, you were able to fix it somehow.  I guess that was before I really 
> figured out much about how it worked, because I don't know what you fixed.
>
> I've made changes to the sample, in the name of fixing off by one errors, 
> and scrollbar settings, and such; and then Laurent changed the way Paint 
> worked.  And some of my fiddlings were after Laurent.
>
> Somewhere along the line, it broke... display a large bitmap, and then a 
> small one, and the large one still has portions remaining on the screen.
>
> It seems that InvalidateRect(1) is called for the window when bitmap sizes 
> are changed, and I sort of thought that was the change that fixed it, but 
> I could be wrong.  But that is still there.
>
> -- 
> Glenn -- http://nevcal.com/
> ===========================
> The best part about procrastination is that you are never bored,
> because you have all kinds of things that you should be doing.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 

[perl-win32-gui-hackers] Committed: fix for SetEvent

[Jez W. <je...@je...>]

Hi,

Just committed the fix for the SetEvent method.

Cheers,

jez.

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

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

At 22:41 2004-10-21, Glenn Linderman wrote:
>Sounds strange.  And does this new/DESTROY happen frequently only after 
>the main window disappears, or all through the execution of the code? And 
>I don't know if DC's are subject to the cascading destruction of their 
>parent window?

There is a DC created and destroyed when painting the Design window. But 
that seems to work ok.

[Not re-creating it if possible sounds like a good optimization btw. 
Painting the window is kind of slow]

Then when I close a preview window the warnings start. I suspect it has 
something to do with the paint event, but I'll investigate further. Maybe 
the DC object isn't created properly or something.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

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

On approximately 10/21/2004 11:18 AM, came the following characters from 
the keyboard of Johan Lindstrom:
> The mouse movement problem was related to the parameters to the mouse 
> movement and click event handlers. In earlier versions the first param 
> was kind of unused (or at least undocumented), and I guess it was 
> removed in this version.
> 
> I'll just branch on version <= 0.9 to get that to work, no biggie.

Hmm.  I thought more parameters were added, rather than removed, as a 
general rule, in Laurent's reworking of the code.  But I didn't look at 
the code for mouse movement and click handlers, so you probably have the 
straight scoop.

Glad this one is straightforward to fix, anyway.

> At 16:59 2004-10-20, Jez White wrote:
> 
>> The global destruction issue, well, good luck tracking that one down:) 
>> When the Loft user closes the test/preview window, do you do anything 
>> special?
> 
> 
> Currently I don't do anything. I guess something happened to the default 
> action of the Window _Terminate event.
> 
> I can work around this, so that in itself doesn't break TGL sufficiently 
> to not release 1.0. But the problem is still there. What happens is this:
> 
> The main window disappears for no reason (perhaps _Terminate returns -1 
> and exits the event loop) and this is spewed:
> Use of uninitialized value in subroutine entry at 
> C:/appl/dev/mod_perl/Perl/site
> /lib/Win32/GUI.pm line 2712 during global destruction.
> 
> That in the the Win32::GUI::DC DESTROY. The $self at that point is an 
> empty hash ref object.
> 
> With a little print statements in new and DESTROY, I can see that DC 
> objects are created and destroyed a LOT for some reason. Maybe something 
> is painted.
> 
> I don't have time to debug more right now, but I'll check it out.

Sounds strange.  And does this new/DESTROY happen frequently only after 
the main window disappears, or all through the execution of the code? 
And I don't know if DC's are subject to the cascading destruction of 
their parent window?

> I suppose I should release a version of TGL that works with both 
> Win32::GUI pre and post 0.9 before we unleash 1.0 on the public. I'm 
> away tomorrow and Saturday, but maybe on Sunday.

I agree this would be an appropriate path.  Although I haven't used TGL, 
I think it is a significant application for Win32::GUI, and I wouldn't 
want to break it with a new release of Win32::GUI, even if it means a 
little delay.

> /J
> -------- ------ ---- --- -- --  --  -     -     -        -          -
> Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

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

The mouse movement problem was related to the parameters to the mouse 
movement and click event handlers. In earlier versions the first param was 
kind of unused (or at least undocumented), and I guess it was removed in 
this version.

I'll just branch on version <= 0.9 to get that to work, no biggie.


At 16:59 2004-10-20, Jez White wrote:
>The global destruction issue, well, good luck tracking that one down:) 
>When the Loft user closes the test/preview window, do you do anything special?

Currently I don't do anything. I guess something happened to the default 
action of the Window _Terminate event.

I can work around this, so that in itself doesn't break TGL sufficiently to 
not release 1.0. But the problem is still there. What happens is this:

The main window disappears for no reason (perhaps _Terminate returns -1 and 
exits the event loop) and this is spewed:
Use of uninitialized value in subroutine entry at 
C:/appl/dev/mod_perl/Perl/site
/lib/Win32/GUI.pm line 2712 during global destruction.

That in the the Win32::GUI::DC DESTROY. The $self at that point is an empty 
hash ref object.

With a little print statements in new and DESTROY, I can see that DC 
objects are created and destroyed a LOT for some reason. Maybe something is 
painted.

I don't have time to debug more right now, but I'll check it out.

I suppose I should release a version of TGL that works with both Win32::GUI 
pre and post 0.9 before we unleash 1.0 on the public. I'm away tomorrow and 
Saturday, but maybe on Sunday.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

[Jez W. <je...@je...>]

Hi,

I've just found a minor problem with SetEvent on combo boxes (but could b=
e=20
with other controls too). So it's probably a good idea to delay the next=20
build.

The global destruction issue, well, good luck tracking that one down:) Wh=
en=20
the Loft user closes the test/preview window, do you do anything special?=
 In=20
the past, I was trying to do weird things with dynamically created object=
s,=20
but with the auto destruction of windows objects in the current build, it=
=20
removes the need for all this trickery (I was getting global destruction=20
errors with that code when I upgraded). I'm still suffering a similar=20
problem with RichEdit controls - if I don't store the RichEdit in a globa=
l=20
variable I get a crash on exit- I was never able to track that problem do=
wn.

Cheers,

jez.


----- Original Message -----=20
From: "Johan Lindstrom" <jo...@Da...>
To: "GUI hackers" <per...@li...>
Cc: "Glenn Linderman" <pe...@ne...>
Sent: Wednesday, October 20, 2004 12:28 AM
Subject: Re: [perl-win32-gui-hackers] GUI 1.0.0 ?


> At 05:18 2004-10-02, Glenn Linderman wrote:
>>Is there anything else stopping us from making Win32::GUI 1.0.0 ?  And=20
>>putting it on CPAN, even, if you have that figured out?
>
> Glenn asked me to check whether TGL would work with the release candida=
te.=20
> I installed the 0.99_1 PPM from SourceForge and tried it out.
>
> After just launching TGL and playing around, it seems like the mouse=20
> selection and clicks are broken (the selection rubber band is in the wr=
ong=20
> place and it doesn't select anything).
>
> When I exit the application, I get a never ending stream of
>
> Use of uninitialized value in subroutine entry at=20
> C:/appl/dev/mod_perl/Perl/site
> /lib/Win32/GUI.pm line 2703 during global destruction.
>
> until I Ctrl-C out of it.
>
>
> So maybe if we could postpone the CPAN upload for a little while? I'll=20
> take a look at this tomorrow.
>
>
> /J
>
> -------- ------ ---- --- -- --  --  -     -     -        -          -
> Johan Lindstr=F6m    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com
>
> Latest bookmark: "TCP Connection Passing"
> http://tcpcp.sourceforge.net/
> dmoz: /Computers/Programming/Languages/JavaScript/ 12
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJourna=
l
> Use IT products in your business? Tell us what you think of them. Give =
us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out=20
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers=20

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

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

At 05:18 2004-10-02, Glenn Linderman wrote:
>Is there anything else stopping us from making Win32::GUI 1.0.0 ?  And 
>putting it on CPAN, even, if you have that figured out?

Glenn asked me to check whether TGL would work with the release candidate. 
I installed the 0.99_1 PPM from SourceForge and tried it out.

After just launching TGL and playing around, it seems like the mouse 
selection and clicks are broken (the selection rubber band is in the wrong 
place and it doesn't select anything).

When I exit the application, I get a never ending stream of

Use of uninitialized value in subroutine entry at 
C:/appl/dev/mod_perl/Perl/site
/lib/Win32/GUI.pm line 2703 during global destruction.

until I Ctrl-C out of it.


So maybe if we could postpone the CPAN upload for a little while? I'll take 
a look at this tomorrow.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

On approximately 10/8/2004 10:42 AM, came the following characters from 
the keyboard of Laurent ROCHER:

> Oups, correct and test it too fast :o)

Yes, and I could see there was a problem, but it took me 3 tries to 
describe it properly!  So I understand the problems of doing things too 
fast.  Glad we have a list and can work things out together.  And thanks 
for fixing it again :)

> It's work when i test because center is default.

Yes, that test case would work.

>>#define SetBits(mask, bits)  {mask |= bits;}
>>#define ResetBits(mask, bits)  {mask &= ~(bits);}
>>#define SwitchBits(mask, bits, set) \
>>  {if (set) SetBits(mask,bits) else ResetBits(mask,bits);}
> 
> 
> Yes, you right. I keep this for later. 
> I don't want to add more stuff now but only bug correction.

Understood.  And I think the above is correct, but I didn't test them. 
Except that memory reads are faster than memory writes, I'm not sure 
that the extra conditionals in the current version of SwitchBit (notice 
I changed the name from SwitchBit to SwitchBits in the above, so they 
could coexist) are an optimization.  Fewer instructions and fewer 
branches would be generated by the code above.. but one more memory 
store guaranteed to be performed by the above, which is made optional by 
the current SwitchBit code with the extra conditionals.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

Oups, correct and test it too fast :o)
It's work when i test because center is default.

> > 
> >> Hi Blair,
> >>
> >>     Fix and commit on CVS.
> > or alternately (to expose that BS_CENTER is BS_LEFT | BS_RIGHT)
> > 
> >               SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
> >               SwitchBit(perlcs->cs.style, BS_LEFT, 1);

I change -center with 2 SwitchBit.

> This is the only one that will work.  SwitchBit is not smart enough to 
> deal with multi-bit values.  If the previous value was BS_RIGHT or 
> BS_LEFT, SwitchBit is not smart enough to only turn on the other bit. 
> Because of its "if(!(mask & bit)) test, which will be false.  Nor is it 
> smart enough to turn off both bits with "SwitchBit(perlcs->cs.style, 
> BS_CENTER,0);", because it uses "mask ^= bit;" which will turn on the 
> other bit.
> 
> Really, it would be easier if there were a primitive that dealt with 
> setting bitfields of variable width.  Such exist, but not as part of 
> Win32::GUI.
> 
> #define SetBits(mask, bits)  {mask |= bits;}
> #define ResetBits(mask, bits)  {mask &= ~(bits);}
> #define SwitchBits(mask, bits, set) \
>   {if (set) SetBits(mask,bits) else ResetBits(mask,bits);}

Yes, you right. I keep this for later. 
I don't want to add more stuff now but only bug correction.

Laurent.

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

On approximately 10/7/2004 3:15 PM, came the following characters from 
the keyboard of Glenn Linderman:

> On approximately 10/7/2004 2:23 PM, came the following characters from 
> the keyboard of Laurent ROCHER:
> 
>> Hi Blair,
>>
>>     Fix and commit on CVS.
>>
>>     Problem come from BS_CENTER style is BS_LEFT | BS_RIGHT so SwitchBit
>> order it's important.
>>
>>     I rewrite like this :
>>
>>     if(strcmp(option, "-align") == 0) {
>>         // BS_CENTER is BS_LEFT | BS_RIGHT
>>         if(strcmp(SvPV_nolen(value), "left") == 0) {
>>             SwitchBit(perlcs->cs.style, BS_RIGHT, 0);
>>             SwitchBit(perlcs->cs.style, BS_LEFT, 1);
>>         } else if(strcmp(SvPV_nolen(value), "center") == 0) {
>>             SwitchBit(perlcs->cs.style, BS_CENTER, 1);
> 
> 
> Shouldn't this be
> 
>               SwitchBit(perlcs->cs.style, BS_CENTER, 3);

No, not this one.  I misread how SwitchBit works.  Sorry for multiple 
postings, but I remembered tha SwitchBit was pretty obscure... but I 
forgot in what way it was obscure.

> or alternately (to expose that BS_CENTER is BS_LEFT | BS_RIGHT)
> 
>               SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
>               SwitchBit(perlcs->cs.style, BS_LEFT, 1);

This is the only one that will work.  SwitchBit is not smart enough to 
deal with multi-bit values.  If the previous value was BS_RIGHT or 
BS_LEFT, SwitchBit is not smart enough to only turn on the other bit. 
Because of its "if(!(mask & bit)) test, which will be false.  Nor is it 
smart enough to turn off both bits with "SwitchBit(perlcs->cs.style, 
BS_CENTER,0);", because it uses "mask ^= bit;" which will turn on the 
other bit.

Really, it would be easier if there were a primitive that dealt with 
setting bitfields of variable width.  Such exist, but not as part of 
Win32::GUI.

#define SetBits(mask, bits)  {mask |= bits;}
#define ResetBits(mask, bits)  {mask &= ~(bits);}
#define SwitchBits(mask, bits, set) \
  {if (set) SetBits(mask,bits) else ResetBits(mask,bits);}

would be more useful, in my opinion.

> 
>>         } else if(strcmp(SvPV_nolen(value), "right") == 0) {
>>             SwitchBit(perlcs->cs.style, BS_LEFT, 0);
>>             SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
>>         } else {
>>             if(PL_dowarn) warn("Win32::GUI: Invalid value for -align!");
>>         }
>>     }
>>
>>     Thank for bug report.
>>
>> Laurent.
>>
>>
>>
>>> I've noticed that the button attribute "align" breaks if you specify
>>> "center", if empty it works (i.e. default).
>>>
>>> <pre>
>>> use Win32::GUI;
>>> my $W = new GUI::Window(-height=>100,-width=>100);
>>> my $B = $W->AddButton(-text=>'Test', -width=>'100', -align=>'center');
>>> $W->Center();
>>> $W->Show();
>>> Win32::GUI::Dialog;
>>> </pre>
>>>
>>> If one replaces "center" with "right" it works as expected. The error is
>>> not apparent in Button.xs and I've happens on XPsp2 and W2Ksp4.
>>>
>>> Blair
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>>
>>
>>
> 

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

On approximately 10/7/2004 2:23 PM, came the following characters from 
the keyboard of Laurent ROCHER:

> Hi Blair,
> 
>     Fix and commit on CVS.
> 
>     Problem come from BS_CENTER style is BS_LEFT | BS_RIGHT so SwitchBit
> order it's important.
> 
>     I rewrite like this :
> 
>     if(strcmp(option, "-align") == 0) {
>         // BS_CENTER is BS_LEFT | BS_RIGHT
>         if(strcmp(SvPV_nolen(value), "left") == 0) {
>             SwitchBit(perlcs->cs.style, BS_RIGHT, 0);
>             SwitchBit(perlcs->cs.style, BS_LEFT, 1);
>         } else if(strcmp(SvPV_nolen(value), "center") == 0) {
>             SwitchBit(perlcs->cs.style, BS_CENTER, 1);

Shouldn't this be

               SwitchBit(perlcs->cs.style, BS_CENTER, 3);

or alternately (to expose that BS_CENTER is BS_LEFT | BS_RIGHT)

               SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
               SwitchBit(perlcs->cs.style, BS_LEFT, 1);

>         } else if(strcmp(SvPV_nolen(value), "right") == 0) {
>             SwitchBit(perlcs->cs.style, BS_LEFT, 0);
>             SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
>         } else {
>             if(PL_dowarn) warn("Win32::GUI: Invalid value for -align!");
>         }
>     }
> 
>     Thank for bug report.
> 
> Laurent.
> 
> 
> 
>>I've noticed that the button attribute "align" breaks if you specify
>>"center", if empty it works (i.e. default).
>>
>><pre>
>>use Win32::GUI;
>>my $W = new GUI::Window(-height=>100,-width=>100);
>>my $B = $W->AddButton(-text=>'Test', -width=>'100', -align=>'center');
>>$W->Center();
>>$W->Show();
>>Win32::GUI::Dialog;
>></pre>
>>
>>If one replaces "center" with "right" it works as expected. The error is
>>not apparent in Button.xs and I've happens on XPsp2 and W2Ksp4.
>>
>>Blair
>>
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

On approximately 10/7/2004 12:57 PM, came the following characters from 
the keyboard of Blair Sutton:
> I've noticed that the button attribute "align" breaks if you specify 
> "center", if empty it works (i.e. default).
> 
> <pre>
> use Win32::GUI;
> my $W = new GUI::Window(-height=>100,-width=>100);
> my $B = $W->AddButton(-text=>'Test', -width=>'100', -align=>'center');
> $W->Center();
> $W->Show();
> Win32::GUI::Dialog;
> </pre>
> 
> If one replaces "center" with "right" it works as expected. The error is 
> not apparent in Button.xs and I've happens on XPsp2 and W2Ksp4.

Hmm.  My button text appears to get centered without any -align option. 
  Perhaps you only need that, to get it to be non-centered?

> Blair

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Win32::GUI::Button align problem

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

Hi Blair,

    Fix and commit on CVS.

    Problem come from BS_CENTER style is BS_LEFT | BS_RIGHT so SwitchBit
order it's important.

    I rewrite like this :

    if(strcmp(option, "-align") == 0) {
        // BS_CENTER is BS_LEFT | BS_RIGHT
        if(strcmp(SvPV_nolen(value), "left") == 0) {
            SwitchBit(perlcs->cs.style, BS_RIGHT, 0);
            SwitchBit(perlcs->cs.style, BS_LEFT, 1);
        } else if(strcmp(SvPV_nolen(value), "center") == 0) {
            SwitchBit(perlcs->cs.style, BS_CENTER, 1);
        } else if(strcmp(SvPV_nolen(value), "right") == 0) {
            SwitchBit(perlcs->cs.style, BS_LEFT, 0);
            SwitchBit(perlcs->cs.style, BS_RIGHT, 1);
        } else {
            if(PL_dowarn) warn("Win32::GUI: Invalid value for -align!");
        }
    }

    Thank for bug report.

Laurent.


> I've noticed that the button attribute "align" breaks if you specify
> "center", if empty it works (i.e. default).
>
> <pre>
> use Win32::GUI;
> my $W = new GUI::Window(-height=>100,-width=>100);
> my $B = $W->AddButton(-text=>'Test', -width=>'100', -align=>'center');
> $W->Center();
> $W->Show();
> Win32::GUI::Dialog;
> </pre>
>
> If one replaces "center" with "right" it works as expected. The error is
> not apparent in Button.xs and I've happens on XPsp2 and W2Ksp4.
>
> Blair
>

[perl-win32-gui-hackers] Win32::GUI::Button align problem

[Blair S. <bs...@nu...>]

I've noticed that the button attribute "align" breaks if you specify 
"center", if empty it works (i.e. default).

<pre>
use Win32::GUI;
my $W = new GUI::Window(-height=>100,-width=>100);
my $B = $W->AddButton(-text=>'Test', -width=>'100', -align=>'center');
$W->Center();
$W->Show();
Win32::GUI::Dialog;
</pre>

If one replaces "center" with "right" it works as expected. The error is 
not apparent in Button.xs and I've happens on XPsp2 and W2Ksp4.

Blair

[perl-win32-gui-hackers] Re: [perl-win32-gui-users] Win32::GUI 0.99_1

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

On approximately 10/2/2004 8:20 AM, came the following characters from 
the keyboard of Laurent ROCHER:
> Hi Win32::GUI users,
>  
>     A new version 0.99_1 of Win32::GUI is availlable at Sourceforge.
>  
>     This is first Release candidate for Win32::GUI 1.0.

>     Please try it, and report any problem :o)

Laurent,

Thanks for updating Changelog with my changes... I forgot.

I've tested out the new version 0.99_1 with all three of my 
applications, and it works at least as well as the prior development 
branch code.  Well, I actually tested my own build of the same code, not 
your PPM, to be precise.  But I did a nmake clean, and a CVS update, so 
all should be the same.

Thanks for doing the release.... on to 1.0 !!

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] bug in Text()

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

> 
> Not something we should hold up the release for; seeing as there seems 
> to be a new release, I guess Laurent agreed on that point!
> 

 I agree, i just finish upload Win32::GUI 0.99_1 at sourceforge :)

Laurent

[perl-win32-gui-hackers] Win32::GUI 0.99_1

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

Hi Win32::GUI users,

    A new version 0.99_1 of Win32::GUI is availlable at Sourceforge.

    This is first Release candidate for Win32::GUI 1.0.

    This version come from main developpement branch of Win32::GUI.

        - Completely new base code.=20
        - Full NEM/OEM support.=20
        - Lot of control Win32 API method.=20
        - Preserved Perl context.=20
        - New DoModal.=20
        - More documentation.=20
        - MDI application support.=20
        - Add MonthCal control.=20
        - ...

    You can find a complet changelog at : =
http://sourceforge.net/project/shownotes.php?release_id=3D272263
    Source and 5.6&5.8 PPM are availlable at : =
http://sourceforge.net/project/showfiles.php?group_id=3D16572
    Documentation generated from source code is availlable at : =
http://perl-win32-gui.sourceforge.net/docs/GUI.html

    Please try it, and report any problem :o)

Cheers,
    Laurent.

Re: [perl-win32-gui-hackers] bug in Text()

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

On approximately 10/2/2004 6:17 AM, came the following characters from 
the keyboard of Jez White:

> It would be nice to be able to create dynamic auto destroying menus 
> too:) You could then create menus based upon dynamic contexts, without 
> worrying about memory leaks. I had a look at implementing this, but it 
> is a big job with the whole menu system needing a redesign (beyond my 
> skills!).

Agreed.  I've been creating dynamic menus by reusing the menu entries, 
via ->Change().  One can change everything, without causing the leaks, 
AFAICT.  Maybe I just haven't leaked rapidly enough to notice.  This is 
limited to menus that stay the same size, though, but with variable content.

Not something we should hold up the release for; seeing as there seems 
to be a new release, I guess Laurent agreed on that point!

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] bug in Text()

[Jez W. <je...@je...>]

> Thanks, Laurent for the explanation.  I think you got your point across. I 
> was unaware of the implications of your new window destruction.

I would put money on that your bug is related to what Laurent suggested, 
I've been bitten twice by similar things.

> So I don't know if there's any "good" solution... in some sense, it would 
> be nice if the destruction of the windows didn't happen until all the 
> references to the windows or subwindows or subelements went away, not just 
> the top one.  So maybe that is why they didn't get destroyed before.  On 
> the other hand, it is nice to be able to have them destroyed somehow.  If 
> the scopes of all the variables for related windows were similar, and 
> generally they should be, then everything would work fine, and things 
> would get destroyed.

Typically, most applications wont notice the 'auto' destruction feature 
since the life of the windows object (window or control) is related to the 
life of the Perl SV. When the latter is destroyed, the window object is 
destroyed too. The "problem" is when the two environments become out of 
sync, which typically happens when windows destroys objects but Perl doesn't 
'know' to destroy the corresponding variable (even if it did know, there is 
very little that could be done anyway) - I don't think there is a way around 
this and the problem would occur in any development environment where 
windows handles are stored.

It's probably worth mentioning that this 'auto' destruction feature is 
extremely powerful and useful concept. It took me a while to break out of 
the mould of creating all windows/controls during initialisation. I'm now 
creating and destroying really complex dynamic windows with no memory leaks. 
The only minus point is that menu's don't work this way and the 'odd bug' 
such as you've highlighted.

It would be nice to be able to create dynamic auto destroying menus too:) 
You could then create menus based upon dynamic contexts, without worrying 
about memory leaks. I had a look at implementing this, but it is a big job 
with the whole menu system needing a redesign (beyond my skills!).

> Perhaps the only useful thing to do now would be to find where someone 
> suggested the technique that I was using, and point out that it is a bad 
> idea now.
>
> The idea was only useful in the first place, if thinking that the window 
> is destroyed, otherwise there is little benefit to it over setting that 
> top window as hidden and disabled.  But if destroying that top window, 
> destroys the child windows (per a Windows feature, and Windows linkages), 
> then the technique clearly isn't a good idea.

Yep - I do something similar myself - I just bury the window reference away 
and forget about it:)

>
> On approximately 10/1/2004 11:12 AM, came the following characters from 
> the keyboard of Laurent ROCHER:
>> Hi,
>>
>>     I think "problem" it's linked with change i made in Win32::GUI for
>> automaticly destroy window when it's perl variable reference count be 
>> null.
>>
>>     In you samples your main window go out of scope, then it's window be
>> destroyed.
>>     But, because it's a parent windows all it's child windows it's 
>> destroyed
>> too (Windows manage like this).
>>     You keep reference of subchild window in your perl variable, but it's
>> linked with a destroyed window and Text do nothing because don't have a
>> valid window handler.
>>
>>     Before, perl reference count wasn't linked to windows life so no 
>> problem
>> here.
>>     Your perl variable was free but not your hide window. And, your 
>> subchild
>> perl variable continue to be linked to a valid windows handle.
>>
>>     I don't know if you understand what i mean (it's difficult for me to
>> explain this in english:)
>>
>> Laurent
>>
>>
>>
>>
>>>At long last, some progress on the bug in Text().  As a reminder, this
>>>failure occurs with the latest development version of Win32::GUI
>>>(0.0.682) but works with one I labeled 0.0.680.  I believe the major
>>>difference is Laurent's reworking of the GUI models.  Which is a big
>>>chunk.  But other things may also have happened.
>>>
>>>By stripping the failing program down from 4851 lines to 286 lines, I
>>>was finally able to focus on many fewer activities that could possibly
>>>be relevent.
>>>
>>>And one surprised me.
>>>
>>>I knew for a long time that immediately prior to returning from the
>>>function that created a Label object in a window (it also created the
>>>window) that the label object returned its initial value via Text().
>>>
>>>However, immediately after the return from the function, the label
>>>object begins returning a zero length string, instead of its initial
>>>value.  And from then on, attempts to set/retrieve other Text values for
>>>that label also fail, with only a zero length string being returned.
>>>
>>>
>>>So, what is the key difference?
>>>
>>>
>>>Well, the test code, available at http://nevcal.com/temporary/bug.pl ,
>>>calls a function which does the following meta-steps:
>>>
>>>    1) Creates a window, storing the handle in a sub scoped my variable,
>>>        and Hide()s it.
>>>    2) Creates another window, using the previous window as its -parent.
>>>        The intention is to avoid a task bar entry, even when the window
>>>        is visible and enabled.
>>>    3) Creates the label, as a widget in the 2nd window, and Hide()s it.
>>>
>>>So when the function returns, the first window handle goes out of scope,
>>>and should be destroyed.  And apparently is.  But with the new version
>>>of GUI, it takes away the functionality of the label->Text(), as well.
>>>With the old version of GUI, the label->Text() continues to function,
>>>even though the first window handle goes out of scope.
>>>
>>>Any clues why there is a difference?  Any good reasons that there should
>>>be a difference?
>>>
>>>At this point I have a workaround... keep the first window handle
>>>around, in a more global variable, and hide and disable that window to
>>>avoid the taskbar entry.  But why should I have to?
>>>
>>>
>>>On approximately 6/28/2004 10:04 PM, came the following characters from
>>>the keyboard of Glenn Linderman:
>>>
>>>>On approximately 6/26/2004 1:30 PM, came the following characters from
>>>>the keyboard of Glenn Linderman:
>>>>
>>>>
>>>>>It seems like the development version of GUI has a bug.
>>>>>
>>>>>The released versions of ->Text() without a parameter return the
>>>>>current value from the object, without resetting it first.
>>>>>
>>>>>The development version of ->Text() without a parameter seems to reset
>>>>>the object, before returning the value.  This eliminates the ability
>>>>>to "read" values.
>>>>>
>>>>>This problem manifested itself to me when attempting to use ->Text()
>>>>>on a Label, I haven't yet investigated to see how many objects might
>>>>>be affected, or looked at the source to see how complex the fix might
>>>>>be...
>>>>>
>>>>>I just happened to use an old program that hadn't been "ported" to the
>>>>>new GUI, with the new GUI, and this symptom cropped up.  Using the old
>>>>>GUI "cured" the problem.
>>>>
>>>>
>>>>This is somewhat a false alarm... but not completely.  I can't reproduce
>>>>it in the "obvious" test case, and the source code for the gui.xs Text
>>>>function, which is the only place Text is defined in either version of
>>>>GUI, is identical.
>>>>
>>>>On the other hand, I do have an application that works fine with the old
>>>> GUI and fails with the new one... same application, and same Perl. And
>>>>the symptom is that data returned from Text() is different.  So I'm
>>>>presently quite confused, but I'll be working on figuring it out.
>>>>
>>>>This is an application that uses 2 threads, via the Win32 Perl fork
>>>>emulation.
>>>>
>>>>In adding a bunch of print statements, I see that with the older
>>>>Win32::GUI, both the parent and child report the same HASH(address) for
>>>>the Label object of concern, whereas the current development version
>>>>reports different HASH(address) values for the Label object of concern.
>>>>
>>>>Yet with the new GUI, the parent starts reporting the different value
>>>>prior to the child thread being created!
>>>>
>>>>One would think that it might be a different sort of scoping or
>>>>different rules for closures, if I weren't using the same version of
>>>>Perl, and just switching GUI versions.
>>>>
>>>>Sort of makes me wonder if there is something about the compilation of
>>>>Win32::GUI that affects the scoping of variables defined later, which
>>>>isn't supposed to happen, of course.  But I'm really grasping at straws
>>>>here.
>>>>
>>>>I've tried to make a small test case, but the small test cases so far
>>>>work identically under the old and new GUI versions.
>>>>
>>>
>>>-- 
>>>Glenn -- http://nevcal.com/
>>>===========================
>>>The best part about procrastination is that you are never bored,
>>>because you have all kinds of things that you should be doing.
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Perl-Win32-GUI-Hackers mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>>
>>
>>
>
> -- 
> Glenn -- http://nevcal.com/
> ===========================
> The best part about procrastination is that you are never bored,
> because you have all kinds of things that you should be doing.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers 

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

[Jez W. <je...@je...>]

> It seems (confirm this if you can Jez) that the "issues" probably only 
> occur for SB_THUMBPOSITION and SB_THUMBTRACK operations, as these are 
> the only that use the position value which is potentially from the 
> WM_HSCROLL or WM_VSCROLL message.
> 
> To allow easier "plumbing", and for the sake of efficiency, I'm adding a 
> special value to the "position" parameter, of -1, which means "use the 
> value from GetScrollInfo  nTrackPos  instead of the passed in value.  So 
>  user code that directly calls Scroll($hv,SB_THUMBPOSITION,$pos) 
> without receiving a message will still work, but user code that says

I've just tested this and works great in practise. Nice.

Cheers,

jez.

Re: [perl-win32-gui-hackers] GUI 1.0.0 ?

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

Hi,

    I prepare all for made a 0.99_1 release for a first 1.0 release
candidate.
    I publish it on sourceforge and try to publish it on CPAN too.

Laurent

>
> Is there anything else stopping us from making Win32::GUI 1.0.0 ?  And
> putting it on CPAN, even, if you have that figured out?
>

[perl-win32-gui-hackers] GUI 1.0.0 ?

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

Hi Laurent,

Well, I think you checked in the fix for the color problem?  Or should I 
go looking for some other problem related to colors?

And you explained by ->Text() issue, once I isolated it.

And you merged Glenn's changes.

And I "fixed" the off-by-one error.

Is there anything else stopping us from making Win32::GUI 1.0.0 ?  And 
putting it on CPAN, even, if you have that figured out?

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.