Hey,
In response to # 1 (textfield problem), make sure that "$window" is
valid. It may be complaining about that, and therefore leading you the
wrong way.
Secondly, my calls to "Add<control>" are typically:
$Textfield = $Window->AddTextfield(
-name => "Textfield",
-left => 10,
-top => 10,
-text => "sample text",
-width => 180,
-height => 22,
-foreground => "#000000",
-background => "#E3E2CC",
);
Make sure you have a "-name" field, this is very common mistake.
For question #2, sorry, I can't help. Just seems strange.
For #3, 'Cancel buttons', why not just delete the others? Or am I
confused on what kind of window you're building?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Dennis Putnam
Sent: Tuesday, July 22, 2003 7:54 AM
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Need some minor cleanup help and a note
on radio buttons
I have finally set up my windows (and learned a lot in the process)
pretty much the way I want and everything is working. But, I have a
couple of cosmetic problems with which I could use some help cleaning
up.
1) I never got an answer to earlier question about an error message I'm
getting when I use Textfields. The error is complaining about an
un-initialized variable in 'GUI.pm'. Further investigation revealed the
specific line (524) it is complaining about is:
my $handle = Win32::GUI::Create($self, $type, @input);
Perhaps someone, considerably more experienced in perl then me, can take
a look at that and see what is going on? As a guess, if $self represents
the id of the object (AddTextfield('objectid',...)) then what is $type?
I'm guessing the array @input represents the properties. Does that means
there needs to be 3 parameters passed in the template, thus:
my $textfield=$window->AddTextfield('fieldid',<something goes here>, {
-name=>...}
);
2) I am getting strange mouse cursor behavior. Actually the mouse works
exactly the way it should but the mouse icon is what is wrong. It seems
that the icon shape stays whatever it was in the last field as it is
moved around the window until it enters an area that changes it. For
example, When the window first comes up the mouse is an hourglass.
Although I can move the window around on the screen, the hourglass will
not change to an arrow until I move it over a checkbox or radio button.
If I move it over a textfield it turns to a text cursor but remains that
until again I move over a field that changes it. How do I get the cursor
to change to the right icon (an arrow) when it leaves a particular field
rather then only when it enters? I seems odd that I would have to
include a lostfocus routine to handle this.
3) My particular application has its own cancel button and cancel
process. The window controls in the upper right create some problems.
How can I disable them?
Thanks for any help on all three of the above.
Now for a note on radio buttons for the archives:
I asked this question earlier but no one replied so I will assume no
one, who read my question, knew the answer. If you do know this already,
well, there is always the delete key.
The question actually expanded into 2 questions neither of which are
addressed by the documentation. Why does tabbing stop at a radio button
even if -tabstop=>0? Since, unlike VC++, radio buttons cannot have the
same name how are they grouped, if one has multiple sets, while
maintaining the mutually exclusive property?
I have to guess the author of this package had a problem implementing
this and the undocumented solution was to use -group and -tabstop rather
then identical names as does VC++. Although I have not tried this for
more then 2 buttons in a set, I suspect it works regardless of how many
buttons are expected to have the mutual exclusive property.
The -group property can only be 0/1 not any number representing some
kind of group ID as I originally thought. I believe it simply begins
grouping objects when it finds one set to 1. Subsequent objects in that
group must have their -group property set to 0 (e.g. the first in a set
of radio buttons has -group=>1 and the rest MUST have -group=>0). When
-group=>1 is encountered again it represents the beginning of a new
group. The -tabstop determines which radio button is on by default, if
any. Only one button, in a group, should have -tabstop=>1, the rest
should be -tabstop=>0 (all can be 0, then none are set initially). I
suspect that the -tabstop property is used to determine if that
particular button is on or not.
That would explain why the checked radio button is included when tabbing
in spite of specifically setting -tabstop=>0. Cosmetically there
apparently is no help for it. IMO, a rather bizarre implementation but
probably the best way to overcome some problem with radio buttons and
groups in general.
I hope this helps someone so they don't have to struggle through this
like I did.
