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: perl-win32-gui-users-admin@lists.sourceforge.net [mailto:perl-win32-gui-users-admin@lists.sourceforge.net] 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>, {

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.