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 -----
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
Stephen, see comments inline:
-----Original Message-----
From: Stephen Pick [mailto:[EMAIL PROTECTED]
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.
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.
if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS style.
[JOE:>>>] Actually, removing the WS_CHILD seemed to fix this problem also.
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.
> 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.
-----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
To: Jez White ; Win32-GUI
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);
}
}
}
