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. if the title bars do not become active, remove the WS_CHILD style. if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS style. 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. I strongly disagree that adding new functionality is bad. The functions I have added are all documented and most have API equivalents. > 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 -----Original Message----- From: Frazier, Joe Jr [mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] -----Original Message----- From: Jez White [mailto:[EMAIL PROTECTED] 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:) 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 ----- From: Stephen Pick <mailto:[EMAIL PROTECTED]> To: Jez White <mailto:[EMAIL PROTECTED]> ; Win32-GUI <mailto:perl-win32-gui-users@lists.sourceforge.net> 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 = new Win32::API("user32","SetParent","NN","N") or croak "Failed to load SetParent from user32.dll"; my $child = new Win32::GUI::DialogBox( -parent => $win, -name => "Child", -left => 0, -top => 0, -text => "Child", -width => 100, -height => 100, -style => 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. =========== 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); } } }
