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

macperl-toolbox-digest V1 #10




macperl-toolbox-digest      Friday, April 9 1999      Volume 01 : Number 010



[MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics
Re: [MacPerl-Toolbox] Event Handling Basics

----------------------------------------------------------------------

Date: Wed, 07 Apr 1999 13:27:48 -0700
From: "Mark Yannuzzi" <myannuzzi@filss.com>
Subject: [MacPerl-Toolbox] Event Handling Basics

I am trying to understand how one handles updating of windows, and in the 
process of looking through the MacPerl book, and the online MacPerl help
have become confused:

1) The MacPerl book makes reference to a 'sethook()' function, beginning on
page 199, and is used to 'set' and event handler:

     $win->sethook('redraw' => \&draw_it)

(I am guessing that a reference to the subroutine draw_it is used due to
some 'order of execution' issue, for lack of a better term. That is, if one
were to place a call to draw_it instead, it would try to execute
immediately, instead of at run-time)

I cannot find the 'sethook()' function (method) in the Mac::Events, or
Mac::Windows online help (or in the corresponding .pm files). I understand
the examples of its use, but was wondering if it is documented anywhere?

2) The examples in the MacPerl book imply that redrawing a window consists
of re-executing the subroutine that drew the contents of the window
initially when the 'redraw' event is detected.  By extension, the
implication is that one has to have 'control' over the window's contents
(i.e, have created the window's content in the first place).  Can one update
(redraw) a window that one has not created the contents, like an "Open" or
"Save" dialog box?

Specifically, what I am trying to do is update a Navigation Services
(Navigation.pm) 'NavGetFile' window, and I'm stuck.  I have found that
simply by placing a dummy event-handling subroutine in the NavGetFile call:

     NavGetFile($defaultLocation, $dialogOptions, $typeList, sub {});

that the dialog box becomes movable and resizable (NavPutFile comes this way
by default, and also seems to 'announce' itself as such, since Default
Folder 3.0.1 modifies the navigation buttons, and adds its own).  So, taking
the advice in Inside Macintosh, I wanted to write a simple subroutine to
handle the updating of the window.

So, I went looking in the Mac::Windows module for a function(s) to do this,
and initially only found the 'BeginUpdate()' and 'EndUpdate()' functions,
but nothing to put between them. But, the MacWindows class seemed to have
two that might be useful, 'redraw' and/or 'update'.

Unsuccessfully, I somewhat blindly tried the following, hoping it would
'connect' the NavGetFile's GrafPtr to a new MacWindow object:

   $inputFiles = NavGetFile($defaultLocation, $dialogOptions, $typeList,
                \&eventProc);
   if (!$inputFiles) {exit}

   sub eventProc()
   {
     my $whatEvent = $_[1]->event->what;
     my $windowID = $_[1]->window;
     my $windowMac = new MacWindow(GetWMgrPort());
     if ($_[0] == kNavCBEvent)
     {
       if ($whatEvent == updateEvt)
       {
         BeginUpdate($windowID);
         $windowMac->redraw;
         EndUpdate($windowID);
       }
     }
   }

I am not sure if this is the best approach, or even a valid one (!), but it
brought a couple of questions to mind:

a) Can one update (redraw) a window that one has not created the contents?
(repeated from earlier to keep all ?'s together)

b) Can a MacWindows object utilize all the constants and functions in the
Mac::Windows module, or only the ones pertaining to it?

b) $macWindow->window "Returns the underlying toolbox GrafPtr" of the
window, is there a way to take an existing window's GrafPtr and associate it
with MacWindows object, so the method's defined for the class can be used?
(I was hoping, praying that my $windowMac = new MacWindow(GetWMgrPort())
might do it, but I don't think it worked).

Any and all instructive comments, leads, or solutions are gratefully
welcomed.


- ----------------------
Mark J. Yannuzzi
myannuzzi@aya.yale.edu

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

------------------------------

Date: Wed, 7 Apr 1999 16:52:10 -0400
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

At 16.27 -0400 1999.04.07, Mark Yannuzzi wrote:
>(I am guessing that a reference to the subroutine draw_it is used due to
>some 'order of execution' issue, for lack of a better term. That is, if one
>were to place a call to draw_it instead, it would try to execute
>immediately, instead of at run-time)

Yes.  You pass a reference and the sub can be called on command.  The idea
is similar to old perl, where you could pass the function name and eval it
later.

  #!perl -wl
  sub foo { print @_ }

  bar('foo');

  sub bar { eval "$_[0] (0..9)" }

Except now we have a much safer and reasonable means:

  #!perl -wl
  sub foo { print @_ }

  bar(\&foo);

  sub bar { &{$_[0]} (0..9) }


>I cannot find the 'sethook()' function (method) in the Mac::Events, or
>Mac::Windows online help (or in the corresponding .pm files). I understand
>the examples of its use, but was wondering if it is documented anywhere?

Mac::Hooks.  :)


>2) The examples in the MacPerl book imply that redrawing a window consists
>of re-executing the subroutine that drew the contents of the window
>initially when the 'redraw' event is detected.  By extension, the
>implication is that one has to have 'control' over the window's contents
>(i.e, have created the window's content in the first place).  Can one update
>(redraw) a window that one has not created the contents, like an "Open" or
>"Save" dialog box?

Not recommended.  You could try it if you are brave.  I don't know how much
you could control it, if at all.


>Specifically, what I am trying to do is update a Navigation Services
>(Navigation.pm) 'NavGetFile' window, and I'm stuck.  I have found that
>simply by placing a dummy event-handling subroutine in the NavGetFile call:
>
>     NavGetFile($defaultLocation, $dialogOptions, $typeList, sub {});
>
>that the dialog box becomes movable and resizable (NavPutFile comes this way
>by default, and also seems to 'announce' itself as such, since Default
>Folder 3.0.1 modifies the navigation buttons, and adds its own).  So, taking
>the advice in Inside Macintosh, I wanted to write a simple subroutine to
>handle the updating of the window.

Ah, that is a little different than dealing with a window you didn't
create, because your function would be, indeed, used by the same "object"
that created the window.

I do not know how to do what you want to do, so I want attempt to help on
the specifics.  :)


>b) Can a MacWindows object utilize all the constants and functions in the
>Mac::Windows module, or only the ones pertaining to it?

Dunno, what are you in particular wondering about?


>b) $macWindow->window "Returns the underlying toolbox GrafPtr" of the
>window, is there a way to take an existing window's GrafPtr and associate it
>with MacWindows object, so the method's defined for the class can be used?
>(I was hoping, praying that my $windowMac = new MacWindow(GetWMgrPort())
>might do it, but I don't think it worked).

Not sure offhand, someone else might know.

Hope this helped in some way, maybe more people can help on other points
you need answers for.

- --
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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

------------------------------

Date: Wed, 07 Apr 1999 14:13:56 -0700
From: "Mark Yannuzzi" <myannuzzi@aya.yale.edu>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

>>I cannot find the 'sethook()' function (method) in the Mac::Events, or
>>Mac::Windows online help (or in the corresponding .pm files). I understand
>>the examples of its use, but was wondering if it is documented anywhere?
>
> Mac::Hooks.  :)
>
Way too obvious! :-). Sorry, I looked in the Shuck/MacPerl sub-menus, and
thought that it was a comprehensive/exhaustive list...guess not, I'll
remember to search the lib directory.


>>2) The examples in the MacPerl book imply that redrawing a window consists
>>of re-executing the subroutine that drew the contents of the window
>>initially when the 'redraw' event is detected.  By extension, the
>>implication is that one has to have 'control' over the window's contents
>>(i.e, have created the window's content in the first place).  Can one update
>>(redraw) a window that one has not created the contents, like an "Open" or
>>"Save" dialog box?
>
> Not recommended.  You could try it if you are brave.  I don't know how much
> you could control it, if at all.
>
>
>>Specifically, what I am trying to do is update a Navigation Services
>>(Navigation.pm) 'NavGetFile' window, and I'm stuck.  I have found that
>>simply by placing a dummy event-handling subroutine in the NavGetFile call:
>>
>>     NavGetFile($defaultLocation, $dialogOptions, $typeList, sub {});
>>
>>that the dialog box becomes movable and resizable (NavPutFile comes this way
>>by default, and also seems to 'announce' itself as such, since Default
>>Folder 3.0.1 modifies the navigation buttons, and adds its own).  So, taking
>>the advice in Inside Macintosh, I wanted to write a simple subroutine to
>>handle the updating of the window.
>
> Ah, that is a little different than dealing with a window you didn't
> create, because your function would be, indeed, used by the same "object"
> that created the window.
>
> I do not know how to do what you want to do, so I want attempt to help on
> the specifics.  :)
>
Thanks, anyway, I just want the window to redraw itself when necessary (for
example, if you click the help button in the dialog box, upon returning the
Mac OS Help, it needs to redraw itself), and I'd also like the cursor to
stop morphing from a standard pointer to the MacPerl Camel "watch dial", and
back, at a rapid rate.

>>b) Can a MacWindows object utilize all the constants and functions in the
>>Mac::Windows module, or only the ones pertaining to it?
>
> Dunno, what are you in particular wondering about?
>
Just whether or not all the constants, types and functions mentioned before
the discussion of the MacWindows class are pertinent to objects of that
type?

Thanks...

- ----------------------
Mark J. Yannuzzi
myannuzzi@aya.yale.edu

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

------------------------------

Date: Wed, 7 Apr 1999 16:19:08 -0500
From: "Jefferson R. Lowrey" <lowrey@mailbag.com>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

>
>>2) The examples in the MacPerl book imply that redrawing a window consists
>>of re-executing the subroutine that drew the contents of the window
>>initially when the 'redraw' event is detected.  By extension, the
>>implication is that one has to have 'control' over the window's contents
>>(i.e, have created the window's content in the first place).  Can one update
>>(redraw) a window that one has not created the contents, like an "Open" or
>>"Save" dialog box?
>
>Not recommended.  You could try it if you are brave.  I don't know how much
>you could control it, if at all.

It's been a while since I've done any toolbox programming, so forgive me if
this isn't entirely helpful.  I'm not actually sure what you're doing that
you want to redraw an Open or Save dialog.  Under pre-Nav services stuff,
the standard file dialog boxes were fairly extensible.  You just have to
create a custom dialog resource, and then make use of the proc hooks to add
the functionality for what you added.

>
>
>>Specifically, what I am trying to do is update a Navigation Services
>>(Navigation.pm) 'NavGetFile' window, and I'm stuck.  I have found that
>>simply by placing a dummy event-handling subroutine in the NavGetFile call:
>>
>>     NavGetFile($defaultLocation, $dialogOptions, $typeList, sub {});
>>
>>that the dialog box becomes movable and resizable (NavPutFile comes this way
>>by default, and also seems to 'announce' itself as such, since Default
>>Folder 3.0.1 modifies the navigation buttons, and adds its own).  So, taking
>>the advice in Inside Macintosh, I wanted to write a simple subroutine to
>>handle the updating of the window.
>
>Ah, that is a little different than dealing with a window you didn't
>create, because your function would be, indeed, used by the same "object"
>that created the window.
>
>I do not know how to do what you want to do, so I want attempt to help on
>the specifics.  :)

I'm also curious why you actually want to update the whole window?  You
should only have to worry about anything you added - and gratefully let the
system handle everything else.

>
>
>>b) $macWindow->window "Returns the underlying toolbox GrafPtr" of the
>>window, is there a way to take an existing window's GrafPtr and associate it
>>with MacWindows object, so the method's defined for the class can be used?
>>(I was hoping, praying that my $windowMac = new MacWindow(GetWMgrPort())
>>might do it, but I don't think it worked).
>

I'd think you'd want to do something different than that.  What I think
you'd want to do is set the grafPort of the new MacWindow to the nav
services window grafPort.

- -Jeff Lowrey



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

------------------------------

Date: Wed, 7 Apr 1999 17:27:42 -0400
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

At 17.13 -0400 1999.04.07, Mark Yannuzzi wrote:
>>>b) Can a MacWindows object utilize all the constants and functions in the
>>>Mac::Windows module, or only the ones pertaining to it?
>>
>> Dunno, what are you in particular wondering about?
>>
>Just whether or not all the constants, types and functions mentioned before
>the discussion of the MacWindows class are pertinent to objects of that
>type?

I don't know.  There's a lot there, and I don't want to look through it all
to find out if each one has something to do with a MacWindow object.

- --
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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

------------------------------

Date: Wed, 7 Apr 1999 17:40:25 -0400 (EDT)
From: rjk@linguist.dartmouth.edu (Ronald J. Kimball)
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

Mark Yannuzzi wrote:
> 
> >>I cannot find the 'sethook()' function (method) in the Mac::Events, or
> >>Mac::Windows online help (or in the corresponding .pm files). I understand
> >>the examples of its use, but was wondering if it is documented anywhere?
> >
> > Mac::Hooks.  :)
> >
> Way too obvious! :-). Sorry, I looked in the Shuck/MacPerl sub-menus, and
> thought that it was a comprehensive/exhaustive list...guess not, I'll
> remember to search the lib directory.
> 

Shuck doesn't even include all the standard Perl documentation in its
menus.  It's actually rather irritating.

Ronald

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

------------------------------

Date: Wed, 7 Apr 1999 20:34:58 -0400
From: Chris Nandor <pudge@pobox.com>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

At 17.40 -0400 1999.04.07, Ronald J. Kimball wrote:
>Shuck doesn't even include all the standard Perl documentation in its
>menus.  It's actually rather irritating.

Fix it.  :)

The MacPerl Help file is just a DB_File database.  I am going to fix my
program to tidy up the MacPerl Help file; I can reupload it if you want.
What it does:

  * Append common names (perlpod) to existing names (Documentation format)
  * Adds to menu the perl*.pod files not already in the menu
  * Goes through lib and site_perl and adds in any modules that are found
    there, so selecting "Mac::AppleEvents::Simple" for help will bring
    up the module, whereas before this would only work for modules that
    were preset in the MacPerl Help file on installation

- --
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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

------------------------------

Date: 08 Apr 1999 08:02:30 +0200
From: Matthias Neeracher <neeri@iis.ee.ethz.ch>
Subject: Re: [MacPerl-Toolbox] Event Handling Basics

In article <199904072038.NAA07566@gateway.LittonSolidState.com>, "Mark Yannuzzi" <myannuzzi@filss.com> writes:

> I am trying to understand how one handles updating of windows, and in the 
> process of looking through the MacPerl book, and the online MacPerl help
> have become confused:

> 2) The examples in the MacPerl book imply that redrawing a window consists
> of re-executing the subroutine that drew the contents of the window
> initially when the 'redraw' event is detected.  By extension, the
> implication is that one has to have 'control' over the window's contents
> (i.e, have created the window's content in the first place).  Can one update
> (redraw) a window that one has not created the contents, like an "Open" or
> "Save" dialog box?

redraw is intended to assume full responibility for the contents, so you
wouldn't use it for those purposes.

> Specifically, what I am trying to do is update a Navigation Services
> (Navigation.pm) 'NavGetFile' window, and I'm stuck.  I have found that
> simply by placing a dummy event-handling subroutine in the NavGetFile call:

>      NavGetFile($defaultLocation, $dialogOptions, $typeList, sub {});

> that the dialog box becomes movable and resizable (NavPutFile comes this way
> by default, and also seems to 'announce' itself as such, since Default
> Folder 3.0.1 modifies the navigation buttons, and adds its own).  So, taking
> the advice in Inside Macintosh, I wanted to write a simple subroutine to
> handle the updating of the window.

Hmm. To do that, you would have to employ a bit of majick. The problem is not
update events for the navigation dialog itself - if you just leave those alone,
Navigation will handle them. You are supposed to handle udpate events for
*background* windows, which you can do by calling Mac::Events::DispatchEvent
for those update events (or, more directly, Mac::Windows::_Update).

> So, I went looking in the Mac::Windows module for a function(s) to do this,
> and initially only found the 'BeginUpdate()' and 'EndUpdate()' functions,
> but nothing to put between them. But, the MacWindows class seemed to have
> two that might be useful, 'redraw' and/or 'update'.

These will be called by the two abovementioned routines.

> Unsuccessfully, I somewhat blindly tried the following, hoping it would
> 'connect' the NavGetFile's GrafPtr to a new MacWindow object:

You probably don't want that, unless you have your own items in the navigation
dialog (and that's a design area I have not tackled myself yet).

>      my $windowMac = new MacWindow(GetWMgrPort());

Main problem with this is that the window manager port is the thing in the
background holding the desktop pattern, not the navigation dialog. Also, you
*don't* want responsibility for update events for the navigation dialog.

> I am not sure if this is the best approach, or even a valid one (!), but it
> brought a couple of questions to mind:

> a) Can one update (redraw) a window that one has not created the contents?
> (repeated from earlier to keep all ?'s together)

No.

> b) Can a MacWindows object utilize all the constants and functions in the
> Mac::Windows module, or only the ones pertaining to it?

You can try anything :-) Most of the functions work on raw windows, i.e.,
- ->window, not on MacPerl window objects.

> b) $macWindow->window "Returns the underlying toolbox GrafPtr" of the
> window, is there a way to take an existing window's GrafPtr and associate it
> with MacWindows object, so the method's defined for the class can be used?

Yeah, your technique is basically OK.

Matthias

- -- 
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

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

------------------------------

End of macperl-toolbox-digest V1 #10
************************************


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