Well, guess again. The documentation describes the old event model:
Events are Perl subs that are called in response to an event that occurred in the user interface, usually generated by an action of the user. For example, a button has a Click event that is called when the user pushes it. The naming convention for events follows the Microsoft Visual Basic's one; its form is:
OBJECTNAME_Eventname
(note there's an underscore in between), where OBJECTNAME is the value of the -name option used when creating the object, and Eventname is the event name, eg. Click. So if you have a button named Button1, your Click event will be defined as follows:
sub Button1_Click {
# ...do something...
}
The code inside will be executed when Button1 gets pressed.
So yeah, it does pollute the namespace. That's why I argued that its good to make the pollution "inaccessable". The new event model uses code refs, but it's quite sparsely documented. See also Re: Global vs. local? (Win32::GUI NEM).
<update>
Since this seems a bit unclear maybe I can clarify. The programmer that uses Win32::GUI does not call the event subroutines himself. The only place you'll usually see "Button1_Click" in the code is in the subroutine declaration. If the programmer has done e.g.
sub Button1_Click { ... }
$main->AddButton(
-name => 'Button1',
...,
);
then it is the Win32::GUI dispatcher that looks in the symbol table for a subroutine named Button1_Click when the button is clicked. Note again that this is in the old event model. In the new event model you would do
$main->AddButton(
-name => 'Button1',
-onClick => sub { ... },
...,
);
</update>
lodin |