From: Peter E. <Pet...@at...> - 2004-01-16 12:49:33
|
You want to add the buttons to the tab, not a child window. So remove all the child window "stuff" and change $childwin->AddButton to $win->Tab->AddButton and now $win will remain in focus. -----Original Message----- From: Jez White [mailto:je...@je...] Sent: Friday, January 16, 2004 7:37 AM To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, The example below will only work on the latest code line from CVS. I'm trying to get my head round using scroll bars. In my test example I want to create a window containing one tab strip. In the tab strip there will be a child window containing a scroll bar and 10 buttons. Scrolling the scroll bar will move the buttons into and out view. Now, the scrolling part works fine - but is using a child window in this way the correct approach? For example, interacting with the child window (clicking on a button, or scrolling) loses focus (which you would expect for a normal window) but is not the correct behaviour in this case. Am I missing something fundamental? Apologies for the dodgy code - is a hack job:) cheers, jez. =========== use Win32::GUI; use Win32::GUI::BorderlessWindow; #create the main window my $win = new Win32::GUI::Window ( -name => "MainWin", -left => 0, -top => 100, -width => 500, -height => 300, -sizable => 1, -text => "Scrollbar Test 2", -noflicker => 1, ); #create a tab strip $win->AddTabStrip ( -name => "Tab", -left => 0, -top => 100, -width => 250, -height => 150, ); $win->Tab->InsertItem(-text => 'Some Tab'); #create a child window with a scroll bar my $childwin = new Win32::GUI::BorderlessWindow ( -name => "Child", -parent =>$win, -left => 10, -top => 250, -width => 200, -height => 120, -hscroll => 1, -noflicker => 1, -onScroll => \&scrolled ); #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name => "Button".$_, -pos => [$_*50, 30], -size => [50, 20], -text => 'Button'.$_,); } #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); $win->Show; $childwin->Show; Win32::GUI::Dialog; sub scrolled { my($object,$bar,$operation,$pos) = @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation == SB_THUMBTRACK) { foreach (0..9) { $string='Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } |
From: Stephen P. <Ste...@uc...> - 2004-01-16 12:58:55
|
Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: =20 use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; =20 my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); =20 $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. =20 After doing this stuff, you'll find you have a dialogbox inside the main = window. It also clips if you drag it "out" of the main window, so it = truely is inside. You can even give it a WS_CAPTION and drag it around = in the client area. =20 Giving things a -parent argument does NOT mean SetParent is called on = them in Win32::GUI. =20 Steve =20 =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, =20 The example below will only work on the latest code line from CVS.=20 =20 I'm trying to get my head round using scroll bars. In my test example I = want to create a window containing one tab strip. In the tab strip there = will be a child window containing a scroll bar and 10 buttons. Scrolling = the scroll bar will move the buttons into and out view. =20 Now, the scrolling part works fine - but is using a child window in this = way the correct approach? For example, interacting with the child window = (clicking on a button, or scrolling) loses focus (which you would expect = for a normal window) but is not the correct behaviour in this case. Am I = missing something fundamental? =20 Apologies for the dodgy code - is a hack job:) =20 cheers, =20 jez. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; =20 #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); =20 #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); =20 #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); =20 #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } =20 #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); =20 $win->Show; $childwin->Show; Win32::GUI::Dialog; =20 sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } =20 |
From: Jez W. <je...@je...> - 2004-01-16 13:34:23
|
Thanks for all the replies/suggestions. I have to admit I'm more confused now than I was when I started:) I tried your suggestions Steve, I end up with something that works like = an MDI application - which is nice in itself, but not what I was after:) = Basically is it possible to use a scroll bar within a window, and not on = one of it's edges? I'm trying to think of a clearer example than my tab = strip one. Imagine a image viewing program with the main window filled = with controls, the image could be larger than the screen so you want to = place scroll bars on the image and not on the window (almost like = putting a scroll bar on a control). I had assumed you could use somesort = of child window to achieve this kind of effect? My thought process was basically inline with what Johan was suggesting - = if a child window could be just another control, then the parent window = would not lose focus and everything would be hunky dory. Using a child = window in this manor would also make sense when attaching a child window = to a band in the rebar control. Or am I just way off the mark here?:) Cheers, jez. ----- Original Message -----=20 From: Stephen Pick=20 To: Jez White ; Win32-GUI=20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. After doing this stuff, you'll find you have a dialogbox inside the = main window. It also clips if you drag it "out" of the main window, so = it truely is inside. You can even give it a WS_CAPTION and drag it = around in the client area. Giving things a -parent argument does NOT mean SetParent is called on = them in Win32::GUI. Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, The example below will only work on the latest code line from CVS.=20 I'm trying to get my head round using scroll bars. In my test = example I want to create a window containing one tab strip. In the tab = strip there will be a child window containing a scroll bar and 10 = buttons. Scrolling the scroll bar will move the buttons into and out = view. Now, the scrolling part works fine - but is using a child window in = this way the correct approach? For example, interacting with the child = window (clicking on a button, or scrolling) loses focus (which you would = expect for a normal window) but is not the correct behaviour in this = case. Am I missing something fundamental? Apologies for the dodgy code - is a hack job:) cheers, jez. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); $win->Show; $childwin->Show; Win32::GUI::Dialog; sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } |
From: Steve P. <st...@ba...> - 2004-01-16 19:24:14
|
Oh, sorry, bugfix, line 83 add: $scrollarea->Left(0 - $scrollwindow->ScrollPos(0)); Helps if you keep tracking the scrollbar during resize :) This stops weird behaviour if you scroll then resize the window. Steve ----- Original Message -----=20 From: Jez White=20 To: Stephen Pick ; Win32-GUI=20 Sent: Friday, January 16, 2004 1:34 PM Subject: Re: [perl-win32-gui-users] Scroll bar example Thanks for all the replies/suggestions. I have to admit I'm more confused now than I was when I started:) I tried your suggestions Steve, I end up with something that works = like an MDI application - which is nice in itself, but not what I was = after:)=20 Basically is it possible to use a scroll bar within a window, and not = on one of it's edges? I'm trying to think of a clearer example than my = tab strip one. Imagine a image viewing program with the main window = filled with controls, the image could be larger than the screen so you = want to place scroll bars on the image and not on the window (almost = like putting a scroll bar on a control). I had assumed you could use = somesort of child window to achieve this kind of effect? My thought process was basically inline with what Johan was suggesting = - if a child window could be just another control, then the parent = window would not lose focus and everything would be hunky dory. Using a = child window in this manor would also make sense when attaching a child = window to a band in the rebar control. Or am I just way off the mark here?:) Cheers, jez. ----- Original Message -----=20 From: Stephen Pick=20 To: Jez White ; Win32-GUI=20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. After doing this stuff, you'll find you have a dialogbox inside the = main window. It also clips if you drag it "out" of the main window, so = it truely is inside. You can even give it a WS_CAPTION and drag it = around in the client area. Giving things a -parent argument does NOT mean SetParent is called = on them in Win32::GUI. Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, The example below will only work on the latest code line from CVS. = I'm trying to get my head round using scroll bars. In my test = example I want to create a window containing one tab strip. In the tab = strip there will be a child window containing a scroll bar and 10 = buttons. Scrolling the scroll bar will move the buttons into and out = view. Now, the scrolling part works fine - but is using a child window = in this way the correct approach? For example, interacting with the = child window (clicking on a button, or scrolling) loses focus (which you = would expect for a normal window) but is not the correct behaviour in = this case. Am I missing something fundamental? Apologies for the dodgy code - is a hack job:) cheers, jez. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); $win->Show; $childwin->Show; Win32::GUI::Dialog; sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } |
From: Jez W. <je...@je...> - 2004-01-16 20:47:16
|
Impressive. It'll take me a bit longer to understand what is actually going on:) This is *really* useful. This example should be included in the next = build.=20 Thanks, jez. ----- Original Message -----=20 From: Steve Pick=20 To: Jez White ; Win32-GUI=20 Sent: Friday, January 16, 2004 7:24 PM Subject: Re: [perl-win32-gui-users] Scroll bar example Oh, sorry, bugfix, line 83 add: $scrollarea->Left(0 - $scrollwindow->ScrollPos(0)); Helps if you keep tracking the scrollbar during resize :) This stops weird behaviour if you scroll then resize the window. Steve |
From: Frazier, J. J. <Joe.Frazier@Peopleclick.com> - 2004-01-16 14:13:27
|
Stephen, that's real nice with the MDI thing. However, there are a few = questions: =20 Do you(the developer) have to control all the window positions and stuff = manually For example, when I set up a second window, and "maximize" one = using the buttons ( I added the -controlbox property), the other windows = floats on top but cannot be interacted with. Neither child window's = title bar would become active. If one window was clipping the other, = the lower window would not come to the foreground when selected. I = think we are really close here to getting some very awesome new = functionality via MDI windows and would perhaps like someone to look = into whatever else is needed to make that happen (although I would = rather have the scroll bar's first in PPM and documented since that is = something I need fairly soon). =20 Now, going back to the subject of new methods, I personally would prefer = against that unless they are aliases for the right way to do things. = Just as XML parsing has problems with "proprietary" methods, I don't = want to have someone how is used to windows programming in VB or C++ to = wonder what something is. If there is something we will do with a new = method that is not in the core API, we need to make sure that it is = fully documented as such. Things that are in the core API should work = the same as they do in other languages, with specific new methods to = change the functionality if we deem that we can get it to work better = doing other things under the hood so to speak. Does anyone else agree = with that? =20 Joe Frazier, Jr. Technical Support Engineer Peopleclick Service Support Tel: +1-800-841-2365 E-Mail: mailto:su...@pe... -----Original Message----- From: Jez White [mailto:je...@je...] Sent: Friday, January 16, 2004 8:35 AM To: Stephen Pick; Win32-GUI Subject: Re: [perl-win32-gui-users] Scroll bar example Thanks for all the replies/suggestions. =20 I have to admit I'm more confused now than I was when I started:) =20 I tried your suggestions Steve, I end up with something that works like = an MDI application - which is nice in itself, but not what I was after:) = =20 Basically is it possible to use a scroll bar within a window, and not on = one of it's edges? I'm trying to think of a clearer example than my tab = strip one. Imagine a image viewing program with the main window filled = with controls, the image could be larger than the screen so you want to = place scroll bars on the image and not on the window (almost like = putting a scroll bar on a control). I had assumed you could use somesort = of child window to achieve this kind of effect? =20 My thought process was basically inline with what Johan was suggesting - = if a child window could be just another control, then the parent window = would not lose focus and everything would be hunky dory. Using a child = window in this manor would also make sense when attaching a child window = to a band in the rebar control. =20 Or am I just way off the mark here?:) =20 Cheers, =20 jez. =20 ----- Original Message -----=20 From: Stephen <mailto:Ste...@uc...> Pick=20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: =20 use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; =20 my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); =20 $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. =20 After doing this stuff, you'll find you have a dialogbox inside the main = window. It also clips if you drag it "out" of the main window, so it = truely is inside. You can even give it a WS_CAPTION and drag it around = in the client area. =20 Giving things a -parent argument does NOT mean SetParent is called on = them in Win32::GUI. =20 Steve =20 =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, =20 The example below will only work on the latest code line from CVS.=20 =20 I'm trying to get my head round using scroll bars. In my test example I = want to create a window containing one tab strip. In the tab strip there = will be a child window containing a scroll bar and 10 buttons. Scrolling = the scroll bar will move the buttons into and out view. =20 Now, the scrolling part works fine - but is using a child window in this = way the correct approach? For example, interacting with the child window = (clicking on a button, or scrolling) loses focus (which you would expect = for a normal window) but is not the correct behaviour in this case. Am I = missing something fundamental? =20 Apologies for the dodgy code - is a hack job:) =20 cheers, =20 jez. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; =20 #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); =20 #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); =20 #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); =20 #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } =20 #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); =20 $win->Show; $childwin->Show; Win32::GUI::Dialog; =20 sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } =20 |
From: Stephen P. <Ste...@uc...> - 2004-01-16 16:26:37
|
Whoa there, slow down... =20 This is NOT an MDI "thing". This is a cheap hack to get Jez's problem = solved. Don't use it unless you have to. =20 if the title bars do not become active, remove the WS_CHILD style. =20 if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS = style. =20 I added new methods that have API equivalents (SetScrollRange, = SetScrollPos...), and I am not the sort of XS programmer who leaves the = user to extract a massive struct which I could have done in XS, which is = why I did not offer SetScrollInfo(), but instead implemented the older = functions that let you do everything SetScrollInfo() does. =20 You must handle all scrolling yourself, as i've said a million times. I = will look into MDIs when I have the time; win32::gui already seems to = have an MDI object but I'm unsure of what it does. =20 I strongly disagree that adding new functionality is bad. The functions = I have added are all documented and most have API equivalents. =20 > I don't want to have someone how is used to windows programming in VB = or > C++ to wonder what something is =20 I do not program XS functions for "VB/VC++ programmers". I write them = for Perl programmers. I respect the fact that originally Win32::API was = supposed to be very similar to the VB way of doing things. That has = changed now. Every new method I add to Win32::GUI attempts to be = in-keeping with the general Win32::GUI way of doing things, and is well = documented. Win32::GUI is still very similar to the underlying C API, = which is a good thing. If they dont know what something is then they can = read the docs, which will be regenerated from the new code and = distributed with the PPM. =20 Steve =20 =20 -----Original Message----- From: Frazier, Joe Jr [mailto:Joe.Frazier@Peopleclick.com] Sent: 16 January 2004 14:15 To: Stephen Pick; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Stephen, that's real nice with the MDI thing. However, there are a few = questions: =20 Do you(the developer) have to control all the window positions and stuff = manually For example, when I set up a second window, and "maximize" one = using the buttons ( I added the -controlbox property), the other windows = floats on top but cannot be interacted with. Neither child window's = title bar would become active. If one window was clipping the other, = the lower window would not come to the foreground when selected. I = think we are really close here to getting some very awesome new = functionality via MDI windows and would perhaps like someone to look = into whatever else is needed to make that happen (although I would = rather have the scroll bar's first in PPM and documented since that is = something I need fairly soon). =20 Now, going back to the subject of new methods, I personally would prefer = against that unless they are aliases for the right way to do things. = Just as XML parsing has problems with "proprietary" methods, I don't = want to have someone how is used to windows programming in VB or C++ to = wonder what something is. If there is something we will do with a new = method that is not in the core API, we need to make sure that it is = fully documented as such. Things that are in the core API should work = the same as they do in other languages, with specific new methods to = change the functionality if we deem that we can get it to work better = doing other things under the hood so to speak. Does anyone else agree = with that? =20 Joe Frazier, Jr. Technical Support Engineer Peopleclick Service Support Tel: +1-800-841-2365 E-Mail: mailto:su...@pe... -----Original Message----- From: Jez White [mailto:je...@je...] Sent: Friday, January 16, 2004 8:35 AM To: Stephen Pick; Win32-GUI Subject: Re: [perl-win32-gui-users] Scroll bar example Thanks for all the replies/suggestions. =20 I have to admit I'm more confused now than I was when I started:) =20 I tried your suggestions Steve, I end up with something that works like = an MDI application - which is nice in itself, but not what I was after:) = =20 Basically is it possible to use a scroll bar within a window, and not on = one of it's edges? I'm trying to think of a clearer example than my tab = strip one. Imagine a image viewing program with the main window filled = with controls, the image could be larger than the screen so you want to = place scroll bars on the image and not on the window (almost like = putting a scroll bar on a control). I had assumed you could use somesort = of child window to achieve this kind of effect? =20 My thought process was basically inline with what Johan was suggesting - = if a child window could be just another control, then the parent window = would not lose focus and everything would be hunky dory. Using a child = window in this manor would also make sense when attaching a child window = to a band in the rebar control. =20 Or am I just way off the mark here?:) =20 Cheers, =20 jez. =20 ----- Original Message -----=20 From: Stephen Pick <mailto:Ste...@uc...> =20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: =20 use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; =20 my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); =20 $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. =20 After doing this stuff, you'll find you have a dialogbox inside the main = window. It also clips if you drag it "out" of the main window, so it = truely is inside. You can even give it a WS_CAPTION and drag it around = in the client area. =20 Giving things a -parent argument does NOT mean SetParent is called on = them in Win32::GUI. =20 Steve =20 =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, =20 The example below will only work on the latest code line from CVS.=20 =20 I'm trying to get my head round using scroll bars. In my test example I = want to create a window containing one tab strip. In the tab strip there = will be a child window containing a scroll bar and 10 buttons. Scrolling = the scroll bar will move the buttons into and out view. =20 Now, the scrolling part works fine - but is using a child window in this = way the correct approach? For example, interacting with the child window = (clicking on a button, or scrolling) loses focus (which you would expect = for a normal window) but is not the correct behaviour in this case. Am I = missing something fundamental? =20 Apologies for the dodgy code - is a hack job:) =20 cheers, =20 jez. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; =20 #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); =20 #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); =20 #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); =20 #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } =20 #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); =20 $win->Show; $childwin->Show; Win32::GUI::Dialog; =20 sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } =20 |
From: Glenn L. <pe...@ne...> - 2004-01-20 01:11:47
|
On approximately 1/16/2004 8:26 AM, came the following characters from the keyboard of Stephen Pick: > You must handle all scrolling yourself, as i've said a million times. I > will look into MDIs when I have the time; win32::gui already seems to > have an MDI object but I'm unsure of what it does. I'll add a note here... I have an app using a Win32::GUI::MDI window, in which I have added a label bitmap, and when the bitmap is larger than the MDI window scroll bars appear, and are active, with no coding on my part except the creation of the window, and the choice of specifically sized bitmaps to put inside the window. The scroll bars retain their state when different bitmaps of different sizes are swapped in, and I haven't figured out if there even is a way to "clear" that state. The scroll bars disappear if the bitmap is small enough. The scroll bars come back when needed. The scroll bars consume space within the MDI window when they appear, but not when they don't. If an old image bigger than the MDI window is replaced by a new image smaller than the MDI window, but big enough it consumes more space than the is available when the scroll bars are displayed, and the scroll bars are not selecting the top left corner of the display, the scroll bars don't go away. Have I seen them go away when they are finally scrolled to the top left corner by the user? I think so. Seems like they should go away immediately, though. Old memories, now, though, so some of this may be a little inaccurate. Seems like this sort of thing could be improved, by someone that knows more about Win32 programming than I have learned so far. -- 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: Frazier, J. J. <Joe.Frazier@Peopleclick.com> - 2004-01-16 17:07:39
|
Stephen, see comments inline: -----Original Message----- From: Stephen Pick [mailto:Ste...@uc...] Sent: Friday, January 16, 2004 11:26 AM To: Frazier, Joe Jr; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Whoa there, slow down... =20 This is NOT an MDI "thing". This is a cheap hack to get Jez's problem = solved. Don't use it unless you have to. [JOE:>>>] Ok, this is not a "real" MDI \ solution, but it is very close = in approximating the functionality. =20 =20 if the title bars do not become active, remove the WS_CHILD style. [JOE:>>>] This did it. The only problem I still see is that both the = child and the parent do not have the ability to have focus. Not sure if = this is just because it is a hack or what not. Of course, when true MDI = functionality can looked at, this will be solved. I currently do not = need MDI windows, but I try to do a quick test any time someone shows = some new code so as to get familiar with the newly added functionality = and how it works. =20 =20 if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS = style. [JOE:>>>] Actually, removing the WS_CHILD seemed to fix this problem = also.=20 =20 I added new methods that have API equivalents (SetScrollRange, = SetScrollPos...), and I am not the sort of XS programmer who leaves the = user to extract a massive struct which I could have done in XS, which is = why I did not offer SetScrollInfo(), but instead implemented the older = functions that let you do everything SetScrollInfo() does. =20 You must handle all scrolling yourself, as i've said a million times. I = will look into MDIs when I have the time; win32::gui already seems to = have an MDI object but I'm unsure of what it does. [JOE:>>>] Thanks. I really appreciate that since I brought up the = scrolling discussion about a week ago and I think where this thread kind = of originated. I away the new PPM and docs so I can play with it(even = though I do not have a current project that needs it, but will in the = near future). =20 I strongly disagree that adding new functionality is bad. The functions = I have added are all documented and most have API equivalents. [JOE:>>>] I apologize if some may have misunderstood my statements. I = was really speaking on the other thread of the SelectAll method that = Glenn was working on. While I have no problem with a new method, my = expectation would be that method names which match those exposed by the = API should function similarly. That's all I was saying. =20 =20 > I don't want to have someone how is used to windows programming in VB = or > C++ to wonder what something is =20 I do not program XS functions for "VB/VC++ programmers". I write them = for Perl programmers. I respect the fact that originally Win32::API was = supposed to be very similar to the VB way of doing things. That has = changed now. Every new method I add to Win32::GUI attempts to be = in-keeping with the general Win32::GUI way of doing things, and is well = documented. Win32::GUI is still very similar to the underlying C API, = which is a good thing. If they dont know what something is then they can = read the docs, which will be regenerated from the new code and = distributed with the PPM. =20 Steve [JOE:>>>] Finally, I wish to thank both you and the others who are = performing active development of this project. It has been very slow = going because of most people relying on Aldo and he is only one person = and can only do so much. While the vast majority of my needs are "very" = simple with regards to using Win32::GUI, I have not felt compelled to = really stretch my designs because the functionally was not there. Due = to your and others ongoing daily work with the project, I feel this will = inspire thing about new ways to build their windows that they may not = have even thought of before. A perfect example is the rebar control. I = have never had a use for it in the past, but after seeing how it works, = I am beginning to image incorporating it into some projects that I have = been considering for a while, but never really started on(i.e., not even = in the requirements phase). Again, I wish to thank you along with the = others who are doing the day to day work on making this awesome utility = even better and more full featured. =20 =20 =20 -----Original Message----- From: Frazier, Joe Jr [mailto:Joe.Frazier@Peopleclick.com] Sent: 16 January 2004 14:15 To: Stephen Pick; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Stephen, that's real nice with the MDI thing. However, there are a few = questions: =20 Do you(the developer) have to control all the window positions and stuff = manually For example, when I set up a second window, and "maximize" one = using the buttons ( I added the -controlbox property), the other windows = floats on top but cannot be interacted with. Neither child window's = title bar would become active. If one window was clipping the other, = the lower window would not come to the foreground when selected. I = think we are really close here to getting some very awesome new = functionality via MDI windows and would perhaps like someone to look = into whatever else is needed to make that happen (although I would = rather have the scroll bar's first in PPM and documented since that is = something I need fairly soon). =20 Now, going back to the subject of new methods, I personally would prefer = against that unless they are aliases for the right way to do things. = Just as XML parsing has problems with "proprietary" methods, I don't = want to have someone how is used to windows programming in VB or C++ to = wonder what something is. If there is something we will do with a new = method that is not in the core API, we need to make sure that it is = fully documented as such. Things that are in the core API should work = the same as they do in other languages, with specific new methods to = change the functionality if we deem that we can get it to work better = doing other things under the hood so to speak. Does anyone else agree = with that? =20 Joe Frazier, Jr. Technical Support Engineer Peopleclick Service Support Tel: +1-800-841-2365 E-Mail: mailto:su...@pe... -----Original Message----- From: Jez White [mailto:je...@je...] Sent: Friday, January 16, 2004 8:35 AM To: Stephen Pick; Win32-GUI Subject: Re: [perl-win32-gui-users] Scroll bar example Thanks for all the replies/suggestions. =20 I have to admit I'm more confused now than I was when I started:) =20 I tried your suggestions Steve, I end up with something that works like = an MDI application - which is nice in itself, but not what I was after:) = =20 Basically is it possible to use a scroll bar within a window, and not on = one of it's edges? I'm trying to think of a clearer example than my tab = strip one. Imagine a image viewing program with the main window filled = with controls, the image could be larger than the screen so you want to = place scroll bars on the image and not on the window (almost like = putting a scroll bar on a control). I had assumed you could use somesort = of child window to achieve this kind of effect? =20 My thought process was basically inline with what Johan was suggesting - = if a child window could be just another control, then the parent window = would not lose focus and everything would be hunky dory. Using a child = window in this manor would also make sense when attaching a child window = to a band in the rebar control. =20 Or am I just way off the mark here?:) =20 Cheers, =20 jez. =20 ----- Original Message -----=20 From: Stephen Pick <mailto:Ste...@uc...> =20 To: Jez White <mailto:je...@je...> ; Win32-GUI = <mailto:per...@li...> =20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: =20 use Win32::API; our $SETPARENT =3D new Win32::API("user32","SetParent","NN","N") or = croak "Failed to load SetParent from user32.dll"; =20 my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); =20 $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. =20 After doing this stuff, you'll find you have a dialogbox inside the main = window. It also clips if you drag it "out" of the main window, so it = truely is inside. You can even give it a WS_CAPTION and drag it around = in the client area. =20 Giving things a -parent argument does NOT mean SetParent is called on = them in Win32::GUI. =20 Steve =20 =20 -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, =20 The example below will only work on the latest code line from CVS.=20 =20 I'm trying to get my head round using scroll bars. In my test example I = want to create a window containing one tab strip. In the tab strip there = will be a child window containing a scroll bar and 10 buttons. Scrolling = the scroll bar will move the buttons into and out view. =20 Now, the scrolling part works fine - but is using a child window in this = way the correct approach? For example, interacting with the child window = (clicking on a button, or scrolling) loses focus (which you would expect = for a normal window) but is not the correct behaviour in this case. Am I = missing something fundamental? =20 Apologies for the dodgy code - is a hack job:) =20 cheers, =20 jez. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; =20 #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); =20 #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); =20 #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); =20 #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } =20 #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); =20 $win->Show; $childwin->Show; Win32::GUI::Dialog; =20 sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } =20 |
From: Jez W. <je...@je...> - 2004-01-16 18:05:16
|
Without meaning to continue the MDI debate - isn't it a dead design methodology? :) I suspect, that I may have confused the situation with me talking about child windows within windows. If Laurent manages to do a new build on the weekend so more of us can get involved in all the new changes, I'll try and use a clearer example. [JOE:>>>] Due to your and others ongoing daily work with the project, I feel this will inspire thing about new ways to build their windows that they may not have even thought of before. The above paragraph sums up very well whats going on with me. I expect that I'll be using all the changes that have gone into Win::32 in the last few weeks - having options at design phase is half the battle. Cheers, jez. ----- Original Message ----- From: Frazier, Joe Jr To: Stephen Pick ; Win32-GUI Sent: Friday, January 16, 2004 5:09 PM Subject: RE: [perl-win32-gui-users] Scroll bar example |
From: Steve P. <st...@ba...> - 2004-01-16 18:16:15
|
Sorry, I have not thrown any weight towards the discussion on Select(-1) = et al, personally I would disagree that it is counter-intuitive, as user = functions such as this one rarely behave like Perl arrays do anyway. I = would say that Select(-1) is perfectly viable, but for readability I = would say that SelectAll() makes more sense. The way I would do it is = implement and document SelectAll(), but quietly make Select(-1) work as = well. That satisfies both people who know what to expect from Select(), = and people who are not familiar with it. SelectAll() would then be = classed as a convenience method. I'm unsure of MDIs, I don't know the "correct" way to implement them = yet, but it may be something to look into in the future. Currently I = have enough stuff to do fixing and documenting the example scripts and = adding to the current docs. Steve ----- Original Message -----=20 From: Frazier, Joe Jr=20 To: Stephen Pick ; Win32-GUI=20 Sent: Friday, January 16, 2004 5:09 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Stephen, see comments inline: -----Original Message----- From: Stephen Pick [mailto:Ste...@uc...] Sent: Friday, January 16, 2004 11:26 AM To: Frazier, Joe Jr; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Whoa there, slow down... This is NOT an MDI "thing". This is a cheap hack to get Jez's = problem solved. Don't use it unless you have to. [JOE:>>>] Ok, this is not a "real" MDI \ solution, but it is very = close in approximating the functionality. =20 if the title bars do not become active, remove the WS_CHILD style. [JOE:>>>] This did it. The only problem I still see is that both = the child and the parent do not have the ability to have focus. Not = sure if this is just because it is a hack or what not. Of course, when = true MDI functionality can looked at, this will be solved. I currently = do not need MDI windows, but I try to do a quick test any time someone = shows some new code so as to get familiar with the newly added = functionality and how it works. =20 if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS = style. [JOE:>>>] Actually, removing the WS_CHILD seemed to fix this problem = also.=20 I added new methods that have API equivalents (SetScrollRange, = SetScrollPos...), and I am not the sort of XS programmer who leaves the = user to extract a massive struct which I could have done in XS, which is = why I did not offer SetScrollInfo(), but instead implemented the older = functions that let you do everything SetScrollInfo() does. You must handle all scrolling yourself, as i've said a million = times. I will look into MDIs when I have the time; win32::gui already = seems to have an MDI object but I'm unsure of what it does. [JOE:>>>] Thanks. I really appreciate that since I brought up the = scrolling discussion about a week ago and I think where this thread kind = of originated. I away the new PPM and docs so I can play with it(even = though I do not have a current project that needs it, but will in the = near future). I strongly disagree that adding new functionality is bad. The = functions I have added are all documented and most have API equivalents. [JOE:>>>] I apologize if some may have misunderstood my statements. = I was really speaking on the other thread of the SelectAll method that = Glenn was working on. While I have no problem with a new method, my = expectation would be that method names which match those exposed by the = API should function similarly. That's all I was saying. =20 > I don't want to have someone how is used to windows programming in = VB or > C++ to wonder what something is I do not program XS functions for "VB/VC++ programmers". I write = them for Perl programmers. I respect the fact that originally Win32::API = was supposed to be very similar to the VB way of doing things. That has = changed now. Every new method I add to Win32::GUI attempts to be = in-keeping with the general Win32::GUI way of doing things, and is well = documented. Win32::GUI is still very similar to the underlying C API, = which is a good thing. If they dont know what something is then they can = read the docs, which will be regenerated from the new code and = distributed with the PPM. Steve [JOE:>>>] Finally, I wish to thank both you and the others who are = performing active development of this project. It has been very slow = going because of most people relying on Aldo and he is only one person = and can only do so much. While the vast majority of my needs are "very" = simple with regards to using Win32::GUI, I have not felt compelled to = really stretch my designs because the functionally was not there. Due = to your and others ongoing daily work with the project, I feel this will = inspire thing about new ways to build their windows that they may not = have even thought of before. A perfect example is the rebar control. I = have never had a use for it in the past, but after seeing how it works, = I am beginning to image incorporating it into some projects that I have = been considering for a while, but never really started on(i.e., not even = in the requirements phase). Again, I wish to thank you along with the = others who are doing the day to day work on making this awesome utility = even better and more full featured. =20 -----Original Message----- From: Frazier, Joe Jr [mailto:Joe.Frazier@Peopleclick.com] Sent: 16 January 2004 14:15 To: Stephen Pick; Win32-GUI Subject: RE: [perl-win32-gui-users] Scroll bar example Stephen, that's real nice with the MDI thing. However, there are = a few questions: Do you(the developer) have to control all the window positions and = stuff manually For example, when I set up a second window, and = "maximize" one using the buttons ( I added the -controlbox property), = the other windows floats on top but cannot be interacted with. Neither = child window's title bar would become active. If one window was = clipping the other, the lower window would not come to the foreground = when selected. I think we are really close here to getting some very = awesome new functionality via MDI windows and would perhaps like someone = to look into whatever else is needed to make that happen (although I = would rather have the scroll bar's first in PPM and documented since = that is something I need fairly soon). Now, going back to the subject of new methods, I personally would = prefer against that unless they are aliases for the right way to do = things. Just as XML parsing has problems with "proprietary" methods, I = don't want to have someone how is used to windows programming in VB or = C++ to wonder what something is. If there is something we will do with = a new method that is not in the core API, we need to make sure that it = is fully documented as such. Things that are in the core API should = work the same as they do in other languages, with specific new methods = to change the functionality if we deem that we can get it to work better = doing other things under the hood so to speak. Does anyone else agree = with that? Joe Frazier, Jr. Technical Support Engineer Peopleclick Service Support Tel: +1-800-841-2365 E-Mail: mailto:su...@pe... -----Original Message----- From: Jez White [mailto:je...@je...] Sent: Friday, January 16, 2004 8:35 AM To: Stephen Pick; Win32-GUI Subject: Re: [perl-win32-gui-users] Scroll bar example Thanks for all the replies/suggestions. I have to admit I'm more confused now than I was when I = started:) I tried your suggestions Steve, I end up with something that = works like an MDI application - which is nice in itself, but not what I = was after:)=20 Basically is it possible to use a scroll bar within a window, = and not on one of it's edges? I'm trying to think of a clearer example = than my tab strip one. Imagine a image viewing program with the main = window filled with controls, the image could be larger than the screen = so you want to place scroll bars on the image and not on the window = (almost like putting a scroll bar on a control). I had assumed you could = use somesort of child window to achieve this kind of effect? My thought process was basically inline with what Johan was = suggesting - if a child window could be just another control, then the = parent window would not lose focus and everything would be hunky dory. = Using a child window in this manor would also make sense when attaching = a child window to a band in the rebar control. Or am I just way off the mark here?:) Cheers, jez. ----- Original Message -----=20 From: Stephen Pick=20 To: Jez White ; Win32-GUI=20 Sent: Friday, January 16, 2004 12:58 PM Subject: RE: [perl-win32-gui-users] Scroll bar example Your code is bad. What you're doing is creating a floating = "BorderlessWindow" positioned over the top of the main window. If you = want to put your window *INSIDE* the client area I suggest you do this: use Win32::API; our $SETPARENT =3D new = Win32::API("user32","SetParent","NN","N") or croak "Failed to load = SetParent from user32.dll"; my $child =3D new Win32::GUI::DialogBox( -parent =3D> $win, -name =3D> "Child", -left =3D> 0, -top =3D> 0, -text =3D> "Child", -width =3D> 100, -height =3D> 100, -style =3D> WS_CHILD, ); $SETPARENT->Call($child->{-handle}, $win->{-handle}); $child->Width($child->Width); # force update. After doing this stuff, you'll find you have a dialogbox = inside the main window. It also clips if you drag it "out" of the main = window, so it truely is inside. You can even give it a WS_CAPTION and = drag it around in the client area. Giving things a -parent argument does NOT mean SetParent is = called on them in Win32::GUI. Steve -----Original Message----- From: per...@li... = [mailto:per...@li...]On Behalf Of = Jez White Sent: 16 January 2004 12:37 To: Win32-GUI Subject: [perl-win32-gui-users] Scroll bar example Hi, The example below will only work on the latest code line = from CVS.=20 I'm trying to get my head round using scroll bars. In my = test example I want to create a window containing one tab strip. In the = tab strip there will be a child window containing a scroll bar and 10 = buttons. Scrolling the scroll bar will move the buttons into and out = view. Now, the scrolling part works fine - but is using a child = window in this way the correct approach? For example, interacting with = the child window (clicking on a button, or scrolling) loses focus (which = you would expect for a normal window) but is not the correct behaviour = in this case. Am I missing something fundamental? Apologies for the dodgy code - is a hack job:) cheers, jez. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D use Win32::GUI; use Win32::GUI::BorderlessWindow; #create the main window my $win =3D new Win32::GUI::Window ( -name =3D> "MainWin", -left =3D> 0, -top =3D> 100, -width =3D> 500, -height =3D> 300, -sizable =3D> 1, -text =3D> "Scrollbar Test 2", -noflicker =3D> 1, ); #create a tab strip $win->AddTabStrip ( -name =3D> "Tab", -left =3D> 0, -top =3D> 100, -width =3D> 250, -height =3D> 150, =20 ); $win->Tab->InsertItem(-text =3D> 'Some Tab'); #create a child window with a scroll bar my $childwin =3D new Win32::GUI::BorderlessWindow ( -name =3D> "Child", -parent =3D>$win, -left =3D> 10, -top =3D> 250, -width =3D> 200, -height =3D> 120, -hscroll =3D> 1, -noflicker =3D> 1, -onScroll =3D> \&scrolled ); #create content for our child window, 10 buttons. foreach (0..9) { $childwin->AddButton ( -name =3D> "Button".$_, -pos =3D> [$_*50, 30], -size =3D> [50, 20], -text =3D> 'Button'.$_,); } #set the scrollbar range and starting pos $childwin->ScrollRange(0,0,450); $childwin->ScrollPos(0,0); $win->Show; $childwin->Show; Win32::GUI::Dialog; sub scrolled { my($object,$bar,$operation,$pos) =3D @_; my $string; $object->Scroll($bar,$operation,$pos); #Scroll the buttons... if($operation =3D=3D SB_THUMBTRACK) { foreach (0..9) { $string=3D'Button'.$_; $childwin->$string->Move(($_*50)-$pos,30); } } } |