Re: [MacPerl-Toolbox] Event Handling Basics

[Matthias Neeracher <neeri@iis.ee.ethz.ch>]

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