Re: [MacPerl] Controls

[ajf@afco.demon.co.uk (Alan Fry)]

>I'm new on the list, but I've scanned the last 6 months of archives and
>don't think that some things related to the Controls Toolbox module have
>been clarified, or whatever. Alan Fry had a question about passing procs
>to TrackControl that I never saw an answer for, posted anyhow.
>
>I worked this stuff through about three months ago when doing a document
>window class that inherits from MacWindow. Scrollbars, window-edge
>goodies, and so forth. I ran into the same problem Alan had:
>
>'Mac::Controls::TrackControl: Last argument must be procedure, 0, or -1'

There is a bug in TrackControl() in verions of MacPerl up to and including
v5.2.0r4 whereby an error results if TrackControl() is given a procedure as
the third parameter. Matthias fixed the bug on the 5th June 1998 and the
revised version of Controls.pm containing the fix is on his site:

        ftp://err.ethz.ch/pub/neeri/MacPerl/Beta/

Normally you would use TestControl() to find out if the control had been
hit and where it had been hit and pass to TrackControl() the control handle
($ctrl) and the point ($pt) e.g.:

        TrackControl($ctrl, $pt, \&trackproc);
        ...
        sub trackproc {
            ($win, $part) = @_
            ...
        }

The function of TrackControl (particularly in relation to scoll bars) is
quite subtle. From the time the mouse goes down on a part TestControl()
returns the part's number until the mouse comes up. In the meantime
TrackControl() is in charge of proceedings.

TrackControl() repeatedly calls the procedure and at each call passes the
part number to it. If the cursor remains on the part, the number passed is
the original part number, but if the the cursor moves off the part (mouse
still down) the number passed is zero.

It is up to the user to monitor the number passed ($part above), and to
turn the scrolling process on or off accordingly.

The script attached was written as an excercise and I hope will clarify the
matter. It is quite a small attachment, but my apologies to all those not
interested in this subject for the nuisance.

>While we're at it, I'm curious about the logic in
>TextEdit::click(), where the PtInRect test doesn't encapsulate TEClick,
>and in TextEdit::redraw(), the InsetRect + FrameRect sequence sure looks
>like a debugging holdover. :-)

I'm not sure I follow -- could you be more specific?

Alan Fry





Attachment converted: mouse1:Scroll.pl (TEXT/McPL) (00006A1E)