Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Glenn L. <pe...@ne...> - 2003-12-31 01:19:52
|
Laurent, and others,
Here is a patch that gives a default event name to every item for which
the user supplies an empty string, instead of just the ones that have a
text string of '-'. It even saves a little code, I think.
It helps a system I am building, and is fully upward compatible with the
existing functionality, so I would appreciate it if it could get into
the next bug-fix release of Win32::GUI. Thanks.
diff -c D:\Win32-GUI-rel-0.0.665\gui.pm gui.pm
*** D:\Win32-GUI-rel-0.0.665\gui.pm Wed Feb 27 04:06:10 2002
--- gui.pm Tue Dec 30 00:16:00 2003
***************
*** 423,431 ****
if(ref($menudata[$i+1])) {
%data = %{$menudata[$i+1]};
} else {
! $data{-name} = $menudata[$i+1];
}
! $level = 0;
$level++ while($text =~ s/^\s*>\s*//);
# print "PM(MakeMenu) processing '$data{-name}', level=$level\n";
--- 436,448 ----
if(ref($menudata[$i+1])) {
%data = %{$menudata[$i+1]};
} else {
! if ( $menudata[$i+1] eq '' )
! { $data{-name} = "dummy$MenuIdCounter";
! } else
! { $data{-name} = $menudata[$i+1];
! }
}
! $level=0;
$level++ while($text =~ s/^\s*>\s*//);
# print "PM(MakeMenu) processing '$data{-name}', level=$level\n";
***************
*** 441,452 ****
} elsif($level == 1) {
$parent = $last{$level-1};
if($text eq "-") {
- $data{-name} = "dummy$MenuIdCounter";
$M->{$data{-name}} = $M->{$parent}->AddMenuItem(
-item => 0,
-id => $MenuIdCounter++,
-separator => 1,
! -name => $data{-name},
);
} else {
$M->{$data{-name}} = $M->{$parent}->AddMenuItem(
--- 458,468 ----
} elsif($level == 1) {
$parent = $last{$level-1};
if($text eq "-") {
$M->{$data{-name}} = $M->{$parent}->AddMenuItem(
-item => 0,
-id => $MenuIdCounter++,
-separator => 1,
! -name => $data{-name},
);
} else {
$M->{$data{-name}} = $M->{$parent}->AddMenuItem(
***************
*** 473,485 ****
);
}
if($text eq "-") {
- $data{-name} = "dummy$MenuIdCounter";
$M->{$data{-name}} =
$M->{$parent."_SubmenuButton"}->AddMenuItem(
-item => 0,
-id => $MenuIdCounter++,
-separator => 1,
! -name => $data{-name},
);
} else {
$M->{$data{-name}} =
--- 489,500 ----
);
}
if($text eq "-") {
$M->{$data{-name}} =
$M->{$parent."_SubmenuButton"}->AddMenuItem(
-item => 0,
-id => $MenuIdCounter++,
-separator => 1,
! -name => $data{-name},
);
} else {
$M->{$data{-name}} =
***************
--
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.
|
|
From: Rafael K. <rki...@ho...> - 2003-12-28 06:48:55
|
Sorry to reply to myself, but I screwed up the line ends in the patch and it didn't seem to go through to the list, anyway it's here: https://sourceforge.net/project/showfiles.php?group_id=72642&package_id= 104552 -- Rafael |
|
From: Steve P. <st...@ba...> - 2003-12-25 01:01:30
|
Just wanted to wish everyone on the list a Merry Christmas and offer my thanks for all your assistance and work on improving Win32::GUI. Cheers, Steve Pick st...@ba... |
|
From: Jez W. <je...@je...> - 2003-12-22 11:48:08
|
I'll have a play and see what I can come up with. Cheers, jez. ----- Original Message ----- From: "Glenn Linderman" <pe...@ne...> To: "Jez White" <je...@je...> Cc: "guihackers" <per...@li...> Sent: Saturday, December 20, 2003 5:55 PM Subject: Re: [perl-win32-gui-hackers] Generic Error handler > Sounds pretty reasonable. For backward compatibility, it should > probably be done as a hook type setting... if the hook is called and > provides an error handler, then the error handler is used, otherwise the > message box gets displayed. And maybe the error handler returns a value > that says whether it handled it or not, and if not, the message box gets > displayed then too. > > Of course, a nicer enhancement would be if the error messages were more > directly related to the error that occurred. A reference to an > undefined value "somewhere" in an XS function call is less useful than > one that would pinpoint the variable of interest, and the line of code. > Maybe such enhancements are impossible, but I know from experience > that eliminating a couple such references from Win32::GUI was like > looking for a needle in a haystack. > > On approximately 12/20/2003 5:53 AM, came the following characters from > the keyboard of Jez White: > > > All, > > > > Would anyone find a generic error handler useful? Instead of win::gui > > displaying the message box when an error occurs it would instead call a > > function passing in the error string. This would allow the application > > to do logging or respond in other ways. > > > > Thoughts? > > > > Cheers, > > > > jez. > > > > > > -- > 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. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
|
From: Glenn L. <pe...@ne...> - 2003-12-20 17:54:57
|
Sounds pretty reasonable. For backward compatibility, it should probably be done as a hook type setting... if the hook is called and provides an error handler, then the error handler is used, otherwise the message box gets displayed. And maybe the error handler returns a value that says whether it handled it or not, and if not, the message box gets displayed then too. Of course, a nicer enhancement would be if the error messages were more directly related to the error that occurred. A reference to an undefined value "somewhere" in an XS function call is less useful than one that would pinpoint the variable of interest, and the line of code. Maybe such enhancements are impossible, but I know from experience that eliminating a couple such references from Win32::GUI was like looking for a needle in a haystack. On approximately 12/20/2003 5:53 AM, came the following characters from the keyboard of Jez White: > All, > > Would anyone find a generic error handler useful? Instead of win::gui > displaying the message box when an error occurs it would instead call a > function passing in the error string. This would allow the application > to do logging or respond in other ways. > > Thoughts? > > Cheers, > > jez. > > -- 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. |
|
From: Jez W. <je...@je...> - 2003-12-20 13:51:49
|
All, Would anyone find a generic error handler useful? Instead of win::gui = displaying the message box when an error occurs it would instead call a = function passing in the error string. This would allow the application = to do logging or respond in other ways. Thoughts? Cheers, jez. |
|
From: Rafael K. <rki...@ho...> - 2003-12-20 02:06:01
|
Hey, Using the work I've done for: http://sourceforge.net/projects/libwin32-exp/ I've made a patch for Win32::GUI with my hints files and portability header. Cheers, -- Rafael |
|
From: Laurent R. <ro...@cl...> - 2003-12-17 19:48:01
|
Win32::GUI::Grid is based on MFCGrid.=20
WM_PRINTCLIENT isn't handle by default with MFC.
I made change for support it in next release.
Grid work nice now with -noflicker option enabled.
I need to see for Scintilla control.
Laurent.
----- Original Message -----=20
From: Jez White=20
To: Stephen Pick ; guihackers=20
Sent: Wednesday, December 17, 2003 1:39 PM
Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Ok. Some more info.
I'm scaling the control in the _Resize handler of the window. I've =
just tried InvalidateRect and had some interesting results. If the =
InvalidateRect is used in the Resize handler nothing happens but if =
InvalidateRect is included an another event, then the control is redrawn =
correctly. As for the grey, same grey as the window background (same for =
the grid control).
The Grid control is by Laurent, and is in C - from memory there might =
have been a board associated with the control too.
23 windows and just under 500 controls - and still growing:)
If you want me to try anything else, drop me an email.
Cheers,
jez. =20
----- Original Message -----=20
From: Stephen Pick=20
To: Jez White ; guihackers=20
Sent: Wednesday, December 17, 2003 12:13 PM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Aha. I know what this is.
A few Windows controls draw themselves (or parts of themselves) =
outside the WM_PAINT DefWndProc. Most should draw in WM_PAINT, but a =
very few (like RichEdits, if I remember correctly) draw when some other =
messages are posted, such as "i have been modified" messages etc. In =
other words, they handle their own redrawing by sending themselves =
messages internally. I'd have to spend some time on MSDN checking out =
where RichEdits actually draw themselves, but I don't have time to dig =
into that right at this minute.
There will obviously need to be a few special cases for controls =
that don't work quite as expected. Are you resizing the richedit control =
with the window (scaling it in the window's xxx_Resize handler), or is =
it just the window on it's own that you are resizing? What happens if =
you InvalidateRect on the richedit control whenever the window is being =
resized? You say you're left with an empty grey control. Is the grey a =
different grey to the window background? If you're left with a dark grey =
box that at least tells me that SOMETHING is being done on WM_PRINT, =
probably - as you said - just the groundwork for subsequent drawing of =
the control contents.
I believe the grid control you mentioned is one of Laurent's modules =
and it uses some third party opensource grid control code written in C, =
I think he links to it on his site so I can have a look through that =
code and find out just why that particular control isn't drawing right. =
One hopes that WM_PRINT is implemented there.
23 windows?!
Steve
-----Original Message-----
From: Jez White [mailto:je...@je...]
Sent: 17 December 2003 11:53
To: Stephen Pick; guihackers
Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Hi,=20
Unfortunately I never received the original email from the list - =
spam filters are at work stopping me receiving some of the posts. I've =
rejoined under a different email address.=20
My app is fairly complex, with hundreds of controls and 23 =
windows. The fact that -noflicker works so well is impressive.=20
The symptoms of the RichEdit control are similar to Grid in that =
the contents aren't visible until the control is changed (say by moving =
the scroll bar). On a resize you can *sometimes* (difficult to reproduce =
on a consistent basis) see the flash of the original contents of the =
RichEdit - all you are left with is an empty grey control. By the looks =
of things the RichEdit draws itself in two phases, the first it greys =
out the contents, and paints the bounding box, and in the second it =
paints the contents. Does this make any sense?=20
I'd be happy to supply examples. I'll try the suggestions you =
made.=20
Cheers,=20
jez.=20
----- Original Message -----=20
From: Stephen Pick=20
To: Jez White ; guihackers=20
Sent: Wednesday, December 17, 2003 10:49 AM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Yes yes yes.
As was posted in the mail regarding the -noflicker option, as =
was written in the documentation for the noflicker option, and as was =
noted in the changelog for the noflicker option: IT BREAKS STUFF. If it =
didnt, it wouldnt be an option.
I'm gratified to see that most of the stuff it's broken for you =
is nonstandard Win32::GUI stuff (I mean, not part of Win32::GUI itself =
but add-ons). I'm surprised that it breaks RichEdit, but not surprised =
that it breaks Graphics.
The -noflicker option should be considered an alpha fix, =
something that I'm working on. You may be able to solve the problem you =
experience with disappearing richedit controls by calling InvalidateRect =
on them, or adding PRF_OWNED to the delivery of the WM_PRINT message in =
the CommonMsgLoops section of the GUI_MessageLoops.cpp file.
Incidentally, the reason it breaks Graphics is because Graphics =
is just a DC, and thus is not "drawn" into a parent DC, but is =
stand-alone. WM_PRINT won't capture the contents of other DCs, it simply =
tells a widget to draw itself into the given DC, and one can't draw a DC =
into a DC.
As far as RichEdit goes, I'm guessing it simply doesnt support =
WM_PRINT at all. It will require some looking into, and if all else =
fails making a compromise by just making the RichEdit and Graphics =
controls flicker like they used to.
Steve
-----Original Message-----
From: per...@li... =
[mailto:per...@li...]On Behalf Of =
Jez White
Sent: 16 December 2003 14:11
To: guihackers
Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs
All,=20
I've been testing with the latest source and I've found =
various issues with the -noflicker option.=20
All the following controls resize correctly, but the contents =
aren't visible until the user interacts with the control (say moving a =
scroll bar). The contents of the control is windows grey.
* Win32::GUI::Grid=20
* Win32::GUI::Scintilla=20
* RichEdit
The following controls resize correctly, and the contents are =
correct but the control still flickers.
* Win32::GUI::AxWindow
* Graphic control
I've had a look through the source - but didn't get anywhere. =
I can provide examples if needed.
Other than the issues, a great option. Nice work.
Cheers,
jez.
|
|
From: Laurent R. <ro...@cl...> - 2003-12-17 18:55:39
|
> I like your IsChild() method much better than my kludge.
> You're welcome to replace my changes in the CVS with your method of doing
it. It seems a much more elegant solution.
OK, i commit IsChild solution on CVS.
Laurent.
|
|
From: Laurent R. <ro...@cl...> - 2003-12-17 18:53:33
|
I commit it on CVS. I add some new methods too and add documentation for all methods. New Methods are :=20 SetImageList GetImageList RemoveImage SetCurSel GetCurSel SetCurFocus GetCurFocus HighlightItem It's some missing TabCtrl macro found in msdn : http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/shellc= c/platform/commctls/tab/reflist.asp Laurent. ----- Original Message -----=20 From: Jez White=20 To: guihackers=20 Sent: Tuesday, December 16, 2003 2:37 PM Subject: [perl-win32-gui-hackers] New Method for TabStrip Hi, Could someone add this new method to TabStrip.xs - it allows you to = associate a imagelist to a tabstrip during runtime. Cheers, jez. = #########################################################################= ## # (@)METHOD:SetImageList(IMAGELIST) HIMAGELIST SetImageList(handle,imagelist) HWND handle HIMAGELIST imagelist CODE: RETVAL =3D TabCtrl_SetImageList(handle, imagelist); OUTPUT: RETVAL |
|
From: Jez W. <je...@je...> - 2003-12-17 12:37:57
|
Ok. Some more info.
I'm scaling the control in the _Resize handler of the window. I've just =
tried InvalidateRect and had some interesting results. If the =
InvalidateRect is used in the Resize handler nothing happens but if =
InvalidateRect is included an another event, then the control is redrawn =
correctly. As for the grey, same grey as the window background (same for =
the grid control).
The Grid control is by Laurent, and is in C - from memory there might =
have been a board associated with the control too.
23 windows and just under 500 controls - and still growing:)
If you want me to try anything else, drop me an email.
Cheers,
jez. =20
----- Original Message -----=20
From: Stephen Pick=20
To: Jez White ; guihackers=20
Sent: Wednesday, December 17, 2003 12:13 PM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Aha. I know what this is.
A few Windows controls draw themselves (or parts of themselves) =
outside the WM_PAINT DefWndProc. Most should draw in WM_PAINT, but a =
very few (like RichEdits, if I remember correctly) draw when some other =
messages are posted, such as "i have been modified" messages etc. In =
other words, they handle their own redrawing by sending themselves =
messages internally. I'd have to spend some time on MSDN checking out =
where RichEdits actually draw themselves, but I don't have time to dig =
into that right at this minute.
There will obviously need to be a few special cases for controls that =
don't work quite as expected. Are you resizing the richedit control with =
the window (scaling it in the window's xxx_Resize handler), or is it =
just the window on it's own that you are resizing? What happens if you =
InvalidateRect on the richedit control whenever the window is being =
resized? You say you're left with an empty grey control. Is the grey a =
different grey to the window background? If you're left with a dark grey =
box that at least tells me that SOMETHING is being done on WM_PRINT, =
probably - as you said - just the groundwork for subsequent drawing of =
the control contents.
I believe the grid control you mentioned is one of Laurent's modules =
and it uses some third party opensource grid control code written in C, =
I think he links to it on his site so I can have a look through that =
code and find out just why that particular control isn't drawing right. =
One hopes that WM_PRINT is implemented there.
23 windows?!
Steve
-----Original Message-----
From: Jez White [mailto:je...@je...]
Sent: 17 December 2003 11:53
To: Stephen Pick; guihackers
Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Hi,=20
Unfortunately I never received the original email from the list - =
spam filters are at work stopping me receiving some of the posts. I've =
rejoined under a different email address.=20
My app is fairly complex, with hundreds of controls and 23 windows. =
The fact that -noflicker works so well is impressive.=20
The symptoms of the RichEdit control are similar to Grid in that the =
contents aren't visible until the control is changed (say by moving the =
scroll bar). On a resize you can *sometimes* (difficult to reproduce on =
a consistent basis) see the flash of the original contents of the =
RichEdit - all you are left with is an empty grey control. By the looks =
of things the RichEdit draws itself in two phases, the first it greys =
out the contents, and paints the bounding box, and in the second it =
paints the contents. Does this make any sense?=20
I'd be happy to supply examples. I'll try the suggestions you made.=20
Cheers,=20
jez.=20
----- Original Message -----=20
From: Stephen Pick=20
To: Jez White ; guihackers=20
Sent: Wednesday, December 17, 2003 10:49 AM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Yes yes yes.
As was posted in the mail regarding the -noflicker option, as was =
written in the documentation for the noflicker option, and as was noted =
in the changelog for the noflicker option: IT BREAKS STUFF. If it didnt, =
it wouldnt be an option.
I'm gratified to see that most of the stuff it's broken for you is =
nonstandard Win32::GUI stuff (I mean, not part of Win32::GUI itself but =
add-ons). I'm surprised that it breaks RichEdit, but not surprised that =
it breaks Graphics.
The -noflicker option should be considered an alpha fix, something =
that I'm working on. You may be able to solve the problem you experience =
with disappearing richedit controls by calling InvalidateRect on them, =
or adding PRF_OWNED to the delivery of the WM_PRINT message in the =
CommonMsgLoops section of the GUI_MessageLoops.cpp file.
Incidentally, the reason it breaks Graphics is because Graphics is =
just a DC, and thus is not "drawn" into a parent DC, but is stand-alone. =
WM_PRINT won't capture the contents of other DCs, it simply tells a =
widget to draw itself into the given DC, and one can't draw a DC into a =
DC.
As far as RichEdit goes, I'm guessing it simply doesnt support =
WM_PRINT at all. It will require some looking into, and if all else =
fails making a compromise by just making the RichEdit and Graphics =
controls flicker like they used to.
Steve
-----Original Message-----
From: per...@li... =
[mailto:per...@li...]On Behalf Of =
Jez White
Sent: 16 December 2003 14:11
To: guihackers
Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs
All,=20
I've been testing with the latest source and I've found various =
issues with the -noflicker option.=20
All the following controls resize correctly, but the contents =
aren't visible until the user interacts with the control (say moving a =
scroll bar). The contents of the control is windows grey.
* Win32::GUI::Grid=20
* Win32::GUI::Scintilla=20
* RichEdit
The following controls resize correctly, and the contents are =
correct but the control still flickers.
* Win32::GUI::AxWindow
* Graphic control
I've had a look through the source - but didn't get anywhere. I =
can provide examples if needed.
Other than the issues, a great option. Nice work.
Cheers,
jez.
|
|
From: Stephen P. <Ste...@uc...> - 2003-12-17 12:13:15
|
Aha. I know what this is. =20 A few Windows controls draw themselves (or parts of themselves) outside = the WM_PAINT DefWndProc. Most should draw in WM_PAINT, but a very few = (like RichEdits, if I remember correctly) draw when some other messages = are posted, such as "i have been modified" messages etc. In other words, = they handle their own redrawing by sending themselves messages = internally. I'd have to spend some time on MSDN checking out where = RichEdits actually draw themselves, but I don't have time to dig into = that right at this minute. =20 There will obviously need to be a few special cases for controls that = don't work quite as expected. Are you resizing the richedit control with = the window (scaling it in the window's xxx_Resize handler), or is it = just the window on it's own that you are resizing? What happens if you = InvalidateRect on the richedit control whenever the window is being = resized? You say you're left with an empty grey control. Is the grey a = different grey to the window background? If you're left with a dark grey = box that at least tells me that SOMETHING is being done on WM_PRINT, = probably - as you said - just the groundwork for subsequent drawing of = the control contents. =20 I believe the grid control you mentioned is one of Laurent's modules and = it uses some third party opensource grid control code written in C, I = think he links to it on his site so I can have a look through that code = and find out just why that particular control isn't drawing right. One = hopes that WM_PRINT is implemented there. =20 23 windows?! =20 Steve -----Original Message----- From: Jez White [mailto:je...@je...] Sent: 17 December 2003 11:53 To: Stephen Pick; guihackers Subject: Re: [perl-win32-gui-hackers] -noflicker Feedback/bugs Hi,=20 Unfortunately I never received the original email from the list - spam = filters are at work stopping me receiving some of the posts. I've = rejoined under a different email address.=20 My app is fairly complex, with hundreds of controls and 23 windows. The = fact that -noflicker works so well is impressive.=20 The symptoms of the RichEdit control are similar to Grid in that the = contents aren't visible until the control is changed (say by moving the = scroll bar). On a resize you can *sometimes* (difficult to reproduce on = a consistent basis) see the flash of the original contents of the = RichEdit - all you are left with is an empty grey control. By the looks = of things the RichEdit draws itself in two phases, the first it greys = out the contents, and paints the bounding box, and in the second it = paints the contents. Does this make any sense?=20 I'd be happy to supply examples. I'll try the suggestions you made.=20 Cheers,=20 jez.=20 ----- Original Message -----=20 From: Stephen <mailto:Ste...@uc...> Pick=20 To: Jez White <mailto:je...@je...> ; guihackers = <mailto:per...@li...> =20 Sent: Wednesday, December 17, 2003 10:49 AM Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs Yes yes yes. =20 As was posted in the mail regarding the -noflicker option, as was = written in the documentation for the noflicker option, and as was noted = in the changelog for the noflicker option: IT BREAKS STUFF. If it didnt, = it wouldnt be an option. =20 I'm gratified to see that most of the stuff it's broken for you is = nonstandard Win32::GUI stuff (I mean, not part of Win32::GUI itself but = add-ons). I'm surprised that it breaks RichEdit, but not surprised that = it breaks Graphics. =20 The -noflicker option should be considered an alpha fix, something that = I'm working on. You may be able to solve the problem you experience with = disappearing richedit controls by calling InvalidateRect on them, or = adding PRF_OWNED to the delivery of the WM_PRINT message in the = CommonMsgLoops section of the GUI_MessageLoops.cpp file. =20 Incidentally, the reason it breaks Graphics is because Graphics is just = a DC, and thus is not "drawn" into a parent DC, but is stand-alone. = WM_PRINT won't capture the contents of other DCs, it simply tells a = widget to draw itself into the given DC, and one can't draw a DC into a = DC. =20 As far as RichEdit goes, I'm guessing it simply doesnt support WM_PRINT = at all. It will require some looking into, and if all else fails making = a compromise by just making the RichEdit and Graphics controls flicker = like they used to. =20 Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 December 2003 14:11 To: guihackers Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs All,=20 =20 I've been testing with the latest source and I've found various issues = with the -noflicker option.=20 =20 All the following controls resize correctly, but the contents aren't = visible until the user interacts with the control (say moving a scroll = bar). The contents of the control is windows grey. =20 * Win32::GUI::Grid=20 * Win32::GUI::Scintilla=20 * RichEdit =20 The following controls resize correctly, and the contents are correct = but the control still flickers. =20 * Win32::GUI::AxWindow * Graphic control =20 I've had a look through the source - but didn't get anywhere. I can = provide examples if needed. =20 Other than the issues, a great option. Nice work. =20 Cheers, =20 jez. =20 |
|
From: Jez W. <je...@je...> - 2003-12-17 11:51:54
|
Hi,=20
Unfortunately I never received the original email from the list - spam =
filters are at work stopping me receiving some of the posts. I've =
rejoined under a different email address.=20
My app is fairly complex, with hundreds of controls and 23 windows. The =
fact that -noflicker works so well is impressive.=20
The symptoms of the RichEdit control are similar to Grid in that the =
contents aren't visible until the control is changed (say by moving the =
scroll bar). On a resize you can *sometimes* (difficult to reproduce on =
a consistent basis) see the flash of the original contents of the =
RichEdit - all you are left with is an empty grey control. By the looks =
of things the RichEdit draws itself in two phases, the first it greys =
out the contents, and paints the bounding box, and in the second it =
paints the contents. Does this make any sense?=20
I'd be happy to supply examples. I'll try the suggestions you made.=20
Cheers,=20
jez.=20
----- Original Message -----=20
From: Stephen Pick=20
To: Jez White ; guihackers=20
Sent: Wednesday, December 17, 2003 10:49 AM
Subject: RE: [perl-win32-gui-hackers] -noflicker Feedback/bugs
Yes yes yes.
As was posted in the mail regarding the -noflicker option, as was =
written in the documentation for the noflicker option, and as was noted =
in the changelog for the noflicker option: IT BREAKS STUFF. If it didnt, =
it wouldnt be an option.
I'm gratified to see that most of the stuff it's broken for you is =
nonstandard Win32::GUI stuff (I mean, not part of Win32::GUI itself but =
add-ons). I'm surprised that it breaks RichEdit, but not surprised that =
it breaks Graphics.
The -noflicker option should be considered an alpha fix, something =
that I'm working on. You may be able to solve the problem you experience =
with disappearing richedit controls by calling InvalidateRect on them, =
or adding PRF_OWNED to the delivery of the WM_PRINT message in the =
CommonMsgLoops section of the GUI_MessageLoops.cpp file.
Incidentally, the reason it breaks Graphics is because Graphics is =
just a DC, and thus is not "drawn" into a parent DC, but is stand-alone. =
WM_PRINT won't capture the contents of other DCs, it simply tells a =
widget to draw itself into the given DC, and one can't draw a DC into a =
DC.
As far as RichEdit goes, I'm guessing it simply doesnt support =
WM_PRINT at all. It will require some looking into, and if all else =
fails making a compromise by just making the RichEdit and Graphics =
controls flicker like they used to.
Steve
-----Original Message-----
From: per...@li... =
[mailto:per...@li...]On Behalf Of =
Jez White
Sent: 16 December 2003 14:11
To: guihackers
Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs
All,=20
I've been testing with the latest source and I've found various =
issues with the -noflicker option.=20
All the following controls resize correctly, but the contents aren't =
visible until the user interacts with the control (say moving a scroll =
bar). The contents of the control is windows grey.
* Win32::GUI::Grid=20
* Win32::GUI::Scintilla=20
* RichEdit
The following controls resize correctly, and the contents are =
correct but the control still flickers.
* Win32::GUI::AxWindow
* Graphic control
I've had a look through the source - but didn't get anywhere. I can =
provide examples if needed.
Other than the issues, a great option. Nice work.
Cheers,
jez.
|
|
From: Stephen P. <Ste...@uc...> - 2003-12-17 10:49:29
|
Yes yes yes. =20 As was posted in the mail regarding the -noflicker option, as was = written in the documentation for the noflicker option, and as was noted = in the changelog for the noflicker option: IT BREAKS STUFF. If it didnt, = it wouldnt be an option. =20 I'm gratified to see that most of the stuff it's broken for you is = nonstandard Win32::GUI stuff (I mean, not part of Win32::GUI itself but = add-ons). I'm surprised that it breaks RichEdit, but not surprised that = it breaks Graphics. =20 The -noflicker option should be considered an alpha fix, something that = I'm working on. You may be able to solve the problem you experience with = disappearing richedit controls by calling InvalidateRect on them, or = adding PRF_OWNED to the delivery of the WM_PRINT message in the = CommonMsgLoops section of the GUI_MessageLoops.cpp file. =20 Incidentally, the reason it breaks Graphics is because Graphics is just = a DC, and thus is not "drawn" into a parent DC, but is stand-alone. = WM_PRINT won't capture the contents of other DCs, it simply tells a = widget to draw itself into the given DC, and one can't draw a DC into a = DC. =20 As far as RichEdit goes, I'm guessing it simply doesnt support WM_PRINT = at all. It will require some looking into, and if all else fails making = a compromise by just making the RichEdit and Graphics controls flicker = like they used to. =20 Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 December 2003 14:11 To: guihackers Subject: [perl-win32-gui-hackers] -noflicker Feedback/bugs All,=20 =20 I've been testing with the latest source and I've found various issues = with the -noflicker option.=20 =20 All the following controls resize correctly, but the contents aren't = visible until the user interacts with the control (say moving a scroll = bar). The contents of the control is windows grey. =20 * Win32::GUI::Grid=20 * Win32::GUI::Scintilla=20 * RichEdit =20 The following controls resize correctly, and the contents are correct = but the control still flickers. =20 * Win32::GUI::AxWindow * Graphic control =20 I've had a look through the source - but didn't get anywhere. I can = provide examples if needed. =20 Other than the issues, a great option. Nice work. =20 Cheers, =20 jez. =20 |
|
From: Stephen P. <Ste...@uc...> - 2003-12-17 10:32:42
|
Hi Laurent,
I like your IsChild() method much better than my kludge. You're welcome =
to replace my changes in the CVS with your method of doing it. It seems =
a much more elegant solution.
Thanks for looking into this,
Steve
-----Original Message-----
From: Laurent ROCHER [mailto:ro...@cl...]
Sent: 16 December 2003 19:13
To: Stephen Pick
Cc: Win32 GUI Hackers
Subject: Re: [perl-win32-gui-hackers] bugfixed some cvs
OK, i understand your problem now.
I agree Main window and Dialog box have screen coordinate.
Dialog box have a parent window but it's not a child window.
No translation must be done.
But, you change break use of -parent option for normal child window =
(show in
my sample).
In this case, it's better to replace in Top and Left :
parent =3D GetParent(handle);
perlud =3D (LPPERLWIN32GUI_USERDATA) GetWindowLong(handle, =
GWL_USERDATA);
if(perlud && perlud->hasParentAttribute =3D=3D FALSE && parent)
ScreenToClient(parent, &myPt);
with :
parent =3D GetParent(handle);
if (parent && IsChild(parent, handle)) ScreenToClient(parent, =
&myPt);
IsChild() do job you want. It's return false when handle is a dialog =
window.
Are you agree ?
Laurent.
----- Original Message -----=20
From: "Stephen Pick"
Subject: RE: [perl-win32-gui-hackers] bugfixed some cvs
Hi,
The problem is simply that the implementation of relative co-ordinates =
is
not done properly.
If you make a parent window and give it a child window that is a =
DialogBox,
then position the main window at screen co-ordinates 100x100, then call
$CHILD->Top(0);
to position child window at the very top of the screen, the child window
will move to the top of the screen but WILL ALSO MOVE 100px TO THE LEFT
because Win32::GUI is treating the relative X co-ordinate it gets using
ScreenToClient() as an absolute co-ordinate when it passes it to
SetWindowPos(). The Y co-ordinate given as the argument (0) is not =
converted
by ScreenToClient() since it's not part of (and not put into) the myRect
struct, and therefore is passed directly to SetWindowPos resulting in
correct, absolute positioning for the Y co-ordinate. The same goes for =
the
Left() function, but the co-ordinate affected by the bug is then the Y
co-ordinate instead of the X co-ordinate.
This is the bug I'm on about, and this is the bug that I believe I have
fixed. The child window must be a DialogBox.
The correct behaviour perhaps, for dialogboxes, is for Top(0) to =
position
them at the Y co-ordinate of their parent, however this is not what I =
would
expect Top(0) to do. To be honest I'm not sure why Win32::GUI makes the
distinction between a Window and a DialogBox anyway, internally both are =
the
same thing with slightly different styles. I can't see any real
justification for just using Win32::GUI::Window at all (other than the =
fact
that it does not suffer from this bug :) ).
The code here demonstrates the problem:
...
If that's the behaviour YOU expect then I strongly disagree with you.
Setting Top() should certainly NOT affect Left().
Steve
|
|
From: Laurent R. <ro...@cl...> - 2003-12-16 19:12:52
|
OK, i understand your problem now.
I agree Main window and Dialog box have screen coordinate.
Dialog box have a parent window but it's not a child window.
No translation must be done.
But, you change break use of -parent option for normal child window (show in
my sample).
In this case, it's better to replace in Top and Left :
parent = GetParent(handle);
perlud = (LPPERLWIN32GUI_USERDATA) GetWindowLong(handle, GWL_USERDATA);
if(perlud && perlud->hasParentAttribute == FALSE && parent)
ScreenToClient(parent, &myPt);
with :
parent = GetParent(handle);
if (parent && IsChild(parent, handle)) ScreenToClient(parent, &myPt);
IsChild() do job you want. It's return false when handle is a dialog window.
Are you agree ?
Laurent.
----- Original Message -----
From: "Stephen Pick"
Subject: RE: [perl-win32-gui-hackers] bugfixed some cvs
Hi,
The problem is simply that the implementation of relative co-ordinates is
not done properly.
If you make a parent window and give it a child window that is a DialogBox,
then position the main window at screen co-ordinates 100x100, then call
$CHILD->Top(0);
to position child window at the very top of the screen, the child window
will move to the top of the screen but WILL ALSO MOVE 100px TO THE LEFT
because Win32::GUI is treating the relative X co-ordinate it gets using
ScreenToClient() as an absolute co-ordinate when it passes it to
SetWindowPos(). The Y co-ordinate given as the argument (0) is not converted
by ScreenToClient() since it's not part of (and not put into) the myRect
struct, and therefore is passed directly to SetWindowPos resulting in
correct, absolute positioning for the Y co-ordinate. The same goes for the
Left() function, but the co-ordinate affected by the bug is then the Y
co-ordinate instead of the X co-ordinate.
This is the bug I'm on about, and this is the bug that I believe I have
fixed. The child window must be a DialogBox.
The correct behaviour perhaps, for dialogboxes, is for Top(0) to position
them at the Y co-ordinate of their parent, however this is not what I would
expect Top(0) to do. To be honest I'm not sure why Win32::GUI makes the
distinction between a Window and a DialogBox anyway, internally both are the
same thing with slightly different styles. I can't see any real
justification for just using Win32::GUI::Window at all (other than the fact
that it does not suffer from this bug :) ).
The code here demonstrates the problem:
...
If that's the behaviour YOU expect then I strongly disagree with you.
Setting Top() should certainly NOT affect Left().
Steve
|
|
From: Laurent R. <ro...@cl...> - 2003-12-16 18:41:14
|
> why 670? No special reason, only sound better than 666 ;o) > > > Does someone have something to add on CVS ? > > yes me! Sorry, i realise, i have probably release new version to fast. But, with Christmas and new year comming soon, i have think a new release before was good idea. Forgive, my enthusiasm. > > 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. > > I will do it immediately. > Thank, i have upload 5.8 PPM. Laurent. |
|
From: Jez W. <je...@je...> - 2003-12-16 14:10:54
|
All,=20 I've been testing with the latest source and I've found various issues = with the -noflicker option.=20 All the following controls resize correctly, but the contents aren't = visible until the user interacts with the control (say moving a scroll = bar). The contents of the control is windows grey. * Win32::GUI::Grid=20 * Win32::GUI::Scintilla=20 * RichEdit The following controls resize correctly, and the contents are correct = but the control still flickers. * Win32::GUI::AxWindow * Graphic control I've had a look through the source - but didn't get anywhere. I can = provide examples if needed. Other than the issues, a great option. Nice work. Cheers, jez. |
|
From: Jez W. <je...@je...> - 2003-12-16 13:37:36
|
Hi,
Could someone add this new method to TabStrip.xs - it allows you to =
associate a imagelist to a tabstrip during runtime.
Cheers,
jez.
=
#########################################################################=
##
# (@)METHOD:SetImageList(IMAGELIST)
HIMAGELIST
SetImageList(handle,imagelist)
HWND handle
HIMAGELIST imagelist
CODE:
RETVAL =3D TabCtrl_SetImageList(handle, imagelist);
OUTPUT:
RETVAL |
|
From: Stephen P. <Ste...@uc...> - 2003-12-16 11:14:59
|
Hi,
The problem is simply that the implementation of relative co-ordinates =
is not done properly.=20
If you make a parent window and give it a child window that is a =
DialogBox, then position the main window at screen co-ordinates 100x100, =
then call
$CHILD->Top(0);
to position child window at the very top of the screen, the child window =
will move to the top of the screen but WILL ALSO MOVE 100px TO THE LEFT =
because Win32::GUI is treating the relative X co-ordinate it gets using =
ScreenToClient() as an absolute co-ordinate when it passes it to =
SetWindowPos(). The Y co-ordinate given as the argument (0) is not =
converted by ScreenToClient() since it's not part of (and not put into) =
the myRect struct, and therefore is passed directly to SetWindowPos =
resulting in correct, absolute positioning for the Y co-ordinate. The =
same goes for the Left() function, but the co-ordinate affected by the =
bug is then the Y co-ordinate instead of the X co-ordinate.
This is the bug I'm on about, and this is the bug that I believe I have =
fixed. The child window must be a DialogBox.
The correct behaviour perhaps, for dialogboxes, is for Top(0) to =
position them at the Y co-ordinate of their parent, however this is not =
what I would expect Top(0) to do. To be honest I'm not sure why =
Win32::GUI makes the distinction between a Window and a DialogBox =
anyway, internally both are the same thing with slightly different =
styles. I can't see any real justification for just using =
Win32::GUI::Window at all (other than the fact that it does not suffer =
from this bug :) ).
The code here demonstrates the problem:
use Win32::GUI;
my $PARENT =3D new Win32::GUI::DialogBox(
-name =3D> "ParentWin",
-left =3D> 100,
-top =3D> 100,
-width =3D> 100,
-height =3D> 100,
-text =3D> "Parent"
);
$PARENT->Show;
my $CHILD =3D new Win32::GUI::DialogBox(
-name =3D> "ChildWin",
-left =3D> 400,
-top =3D> 200,
-width =3D> 100,
-height =3D> 100,
-text =3D> "Child",
-parent =3D> $PARENT
);
$PARENT->AddButton(
-name =3D> "movechild",
-left =3D> 10,
-top =3D> 10,
-right =3D> 10,
-width =3D> 70,
-height =3D> 25,
-text =3D> "Move child"
);
$CHILD->Show;
Win32::GUI::Dialog;
sub ::movechild_Click {
print "Child X co-ordinate: ".$CHILD->Left()."\n";
$CHILD->Top(0);
print "Child X co-ordinate after Top(0): ".$CHILD->Left()."\n";
return 0;
};
If that's the behaviour YOU expect then I strongly disagree with you. =
Setting Top() should certainly NOT affect Left().
Steve
-----Original Message-----
From: per...@li...
[mailto:per...@li...]On Behalf Of
Laurent ROCHER
Sent: 15 December 2003 23:03
To: Steve Pick
Cc: Win32 GUI Hackers
Subject: Re: [perl-win32-gui-hackers] bugfixed some cvs
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.
I'm not understand your problem and bug fix.
For me, coordinate of a child windows is relative to parent window and =
not
screen relative.
Only main window are screen coordinate.
I have test sample below with your change, and button move when sizing =
or
main window move.
Button should alway be at 5,5 in main window, with AddButton or with new
GUI::Button + parent option.
use Win32::GUI;
$W =3D new Win32::GUI::Window(
-title =3D> "test",
-left =3D> 100,
-top =3D> 100,
-width =3D> 280,
-height =3D> 280,
-name =3D> "Window",
);
# $button =3D $W->AddButton( # This keep button =
as 5,5
$button =3D new Win32::GUI::Button( -parent =3D> $W, # This move button
-name =3D> "Simple1",
-left =3D> 5,
-top =3D> 5,
-width =3D> 122,
-height =3D> 400,
-text =3D> "Just button",
);
$W->Show;
Win32::GUI::Dialog();
sub Window_Terminate {
return -1;
}
sub Window_Resize {
$button->Left(5);
$button->Top(5);
print "Resize !!!\n";
}
>
> 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.
If you want move or hide a group of widget, it's better to create all =
widget
directly to a parent/container window.
And move or hide this container window.
Some thing like that :
use Win32::GUI;
$W =3D new Win32::GUI::Window(
-title =3D> "test",
-pos =3D> [100, 100],
-size =3D> [280, 280],
-name =3D> "Window",
);
$Grp1 =3D $W->AddGroupbox(
-name =3D> "Groupe",
-text =3D> "Groupe",
-pos =3D> [5, 5],
-size =3D> [122, 200],
);
new Win32::GUI::Button (
-parent =3D> $Grp1,
-name =3D> "Test",
-text =3D> "Test!!!",
-pos =3D> [20, 20]
);
$W->AddButton (
-name =3D> "Hide",
-text =3D> "Hide it",
-pos =3D> [200, 5],
);
$W->AddButton (
-name =3D> "Show",
-text =3D> "Show it",
-pos =3D> [ 200, 40],
);
$W->AddButton (
-name =3D> "Move",
-text =3D> "Move it",
-pos =3D> [200, 75],
);
$W->Show;
Win32::GUI::Dialog();
sub Window_Terminate { return -1; }
sub Test_Click { print "test !!!\n"; }
sub Hide_Click { $Grp1->Hide(); }
sub Show_Click { $Grp1->Show(); }
sub Move_Click { $Grp1->Top($Grp1->Top + 2); }
You can look on my TabFrame package, i have a Frame.pm class with act as
window container.
Frame heritate from Win32::GUI::Window so you can use standard =
Add<Control>
method.
If you really need use SetParent for runtime change, i think it's =
probably
better to add set functionnality to AbsLeft and AbsTop.
And use those functions rather Left and Top.
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
|
|
From: Aldo C. <da...@pe...> - 2003-12-16 10:11:58
|
Laurent ROCHER wrote: > I commit : > [Laurent Rocher] > - GUI.pm : Change version to 0.0.670 why 670? > Does someone have something to add on CVS ? yes me! > Where upload new package release ? on SourceForge. > 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. I will do it immediately. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; |
|
From: Laurent R. <ro...@cl...> - 2003-12-15 23:05:39
|
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.
I'm not understand your problem and bug fix.
For me, coordinate of a child windows is relative to parent window and not
screen relative.
Only main window are screen coordinate.
I have test sample below with your change, and button move when sizing or
main window move.
Button should alway be at 5,5 in main window, with AddButton or with new
GUI::Button + parent option.
use Win32::GUI;
$W = new Win32::GUI::Window(
-title => "test",
-left => 100,
-top => 100,
-width => 280,
-height => 280,
-name => "Window",
);
# $button = $W->AddButton( # This keep button as 5,5
$button = new Win32::GUI::Button( -parent => $W, # This move button
-name => "Simple1",
-left => 5,
-top => 5,
-width => 122,
-height => 400,
-text => "Just button",
);
$W->Show;
Win32::GUI::Dialog();
sub Window_Terminate {
return -1;
}
sub Window_Resize {
$button->Left(5);
$button->Top(5);
print "Resize !!!\n";
}
>
> 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.
If you want move or hide a group of widget, it's better to create all widget
directly to a parent/container window.
And move or hide this container window.
Some thing like that :
use Win32::GUI;
$W = new Win32::GUI::Window(
-title => "test",
-pos => [100, 100],
-size => [280, 280],
-name => "Window",
);
$Grp1 = $W->AddGroupbox(
-name => "Groupe",
-text => "Groupe",
-pos => [5, 5],
-size => [122, 200],
);
new Win32::GUI::Button (
-parent => $Grp1,
-name => "Test",
-text => "Test!!!",
-pos => [20, 20]
);
$W->AddButton (
-name => "Hide",
-text => "Hide it",
-pos => [200, 5],
);
$W->AddButton (
-name => "Show",
-text => "Show it",
-pos => [ 200, 40],
);
$W->AddButton (
-name => "Move",
-text => "Move it",
-pos => [200, 75],
);
$W->Show;
Win32::GUI::Dialog();
sub Window_Terminate { return -1; }
sub Test_Click { print "test !!!\n"; }
sub Hide_Click { $Grp1->Hide(); }
sub Show_Click { $Grp1->Show(); }
sub Move_Click { $Grp1->Top($Grp1->Top + 2); }
You can look on my TabFrame package, i have a Frame.pm class with act as
window container.
Frame heritate from Win32::GUI::Window so you can use standard Add<Control>
method.
If you really need use SetParent for runtime change, i think it's probably
better to add set functionnality to AbsLeft and AbsTop.
And use those functions rather Left and Top.
Laurent.
|
|
From: Glenn L. <pe...@ne...> - 2003-12-15 21:22:12
|
On approximately 12/14/2003 8:22 AM, came the following characters from the keyboard of Steve Pick: > 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. Ah. Tree and listviews are not commonly found in my current applications. No wonder I haven't noticed the flicker. -noflicker sounds like a good way to go, though, as your solution does sound somewhat drastic, in the sense that there are incompatibilities and side-effects, which, although perhaps not terribly severe, could affect some applications. -- 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. |
|
From: Steve P. <st...@ba...> - 2003-12-14 22:43:21
|
Hi, Just committed the flicker-free windows code. This prevents any flickering of widgets in a window when it's resized. Because the code may break your current windows (for instance, graphic objects now do not show up, and WS_CLIPCHILDREN causes no the background to not be redrawn) you must explicitly turn it on with the -noflicker => 1 option for your window. Steve |
|
From: Steve P. <st...@ba...> - 2003-12-14 22:24:58
|
The archive is always a few days out of date, but I can't imagine why you're not getting some messages. Spam filtering? Steve ----- Original Message ----- From: "Jeremy White" <jez...@ho...> To: <ro...@cl...>; <st...@ba...> Cc: <per...@li...> Sent: Sunday, December 14, 2003 7:58 PM Subject: Re: [perl-win32-gui-hackers] Success with flicker-free windows! > 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 > > |
18 messages has been excluded from this view by a project administrator.
