[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

[MacPerl-Toolbox] A difficulty with Hooks.pm



Discussions following a recent question on this list prompts me to 
raise what I think is a fundamental problem with Hooks.pm. In the 
event of a new distribution of MacPerl perhaps the matter could be 
reconsidered.

Most if not all 'hooks' are called from Windows by a line similar to 
this for the 'key' hook:

     defined($handled = $self->callhook("key", @_)) and return $handled;

In other words the Event is regarded as dealt with if something 
tangible comes back from 'callhook'. In most (but not all) cases the 
call to 'hooks' is made before the Event is dispatched to the 'panes'.

Now you might think that you could (for instance) couple a CR to an 
"OK Button" in a MacWindow ($win), in the usual Mac fashion, by the 
following procedure:

	$win->sethook('key', sub {
		if ($_[1] == 13) { $OK = 1; return 1 }  # CR handled
                 else { return undef }                   # other keys 
not handled
	    }
	);

In other words if the CR key is hit <$OK = 1> does whatever you want 
the 'OK Button' to do, and the Event is regarded as closed. Any other 
key stroke would by contrast pass to the panes.

However if you look at Hooks.pm you find a line:

	$hook = "sort of defined" unless defined $hook;

with the result (in the example above) that instead of an 'undef' 
being returned to Windows.pm by keys other than CR, the string "sort 
of defined" is received. This is regarded by the Event Manager as 
"sort of true, really", thus defeating the object of the exercise.

I feel strongly that that line should simply be removed from 
Hooks.pm, so that the programmer is free to return an 'undef' if he 
wants to.

Few scripts should break as a result. In all cases where a hook is 
not set, an 'undef' would be returned as it is now. Scripts which 
just depend on a null hook like, for instance:

	$win->sethook('drawgrowicon', sub {});

would fail it's true, but would need only a 1 in the curly brackets 
to fix. Almost any other real-life subroutine one could conceive of, 
will return something (after all <print 'Hello World'> will return a 
1) and any very rare exceptions can always be fixed with a  'return 
1'.

Does anyone agree or disagree?

Alan Fry





==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-toolbox-request@macperl.org