Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 2/csmp-v2-015.txt

Text File | 1994-12-08 | 35.3 KB | 895 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 23 Feb 93       Volume 2 : Issue 15

Today's Topics:

    Disabling editBox items (long)
    setwindowpic
    Modifying width of PopUp menus in System 7.1
    Finding Application to Launch
    Slow drawing under System 7
    Color animation in After Dark...HELP!



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the usenet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you can
post articles to any newsgroup by mailing your article to
    [e-mail]
So, to post an article to comp.sys.mac.programmer, mail your article to
    [e-mail]
Note the '-' instead of '.' in the newsgroup name.  Be sure to ask that
replies be emailed to you instead of posted to the group, and give your
email address.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


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

From: [e-mail] (Jesse Jones)
Subject: Disabling editBox items (long)
Date: 22 Jan 1993 03:59:27 GMT
Organization: University of Washington, Seattle


   There have been several posts asking how to disable editBox's in the last
year or so. I had some code that did the trick for a dialog with one editBox,
but it was a bit of a hack involving a userItem and a hidden editBox. A few
days ago I modified another of the dialogs in my program so that it required
two editBox's to be disabled. Naturaly I took the opportunity to rewrite my
code in a more general fashion.

   The new code requires that the dialog procedure call only two procedures,
works with any number of editBox's, can disable/enable any number of editBox's,
and doesn't require any modifications to the DITL list. The two required
procedures are listed below:

PROCEDURE EnableEditBox (dptr: DialogPtr; item: INTEGER; enable: BOOLEAN);

PROCEDURE GreyFilter (dptr: DialogPtr; VAR Event: EventRecord;
                             VAR item: INTEGER): BOOLEAN;

EnableEditBox should be called once at the start of the dialog procedure to
either disable the item or enable it (it may have been disabled the last
time the dialog procedure was called). The GreyFilter is a filter proc passed
to ModalDialog. It's used to grey out the editBox's when an update event occurs.
You can, of course, use your own filter proc as long as you also call
GreyFilter. And that's all there is to using the code!

   The code itself is a bit more complex. To keep track of the disabled
editBox's I place a handle to an array of booleans in the dialog's window refCon.
The size of the array is determined by the number of items in the dialog. If an
element in the array is TRUE then the editBox with corresponding item number is
disabled. The type declaration for the array is shown below.

TYPE
    GreyHand = POINTER TO GreyPtr;
    GreyPtr  = POINTER TO GreyList;
    GreyList = ARRAY [1..1000] OF BOOLEAN;

   When the EnableEditBox procedure disables an editBox it first checks to see
if the editBox is the currently selected editBox. If it is selected the below
procedure is called to find another editBox to select.

PROCEDURE GetAnotherEditBox (dptr: DialogPtr; item: INTEGER): INTEGER;
    VAR
        peek : DialogPeek;
        index: INTEGER;
        type : INTEGER;
        data : HANDLE;
        box  : Rect;
BEGIN
    peek := DialogPeek(dptr);
    FOR index := 1 TO INT(peek^.items^^)+1 DO
        GetDItem(dptr, index, type, data, box);
        type := And(type, 127);                (* mask out itemDisable flag *)
        IF (type = editText) AND (index <> item) THEN RETURN index END;
    END;
    RETURN 0;                                    (* return 0 if can't find an editBox *)
END GetAnotherEditBox;

   And now we come to the central procedure, EnableEditBox. This procedure does
the following:
    1) Init the array of disabled editBox's. NewHandleClear is used so that all
        the of the elements start out FALSE.
    2) GetDItem is called to find the type for the item. The itemDisable flag
        is then masked out so that we can use a simple equality test with editBox.
    3) To disable an editBox it is first changed to a staticText item. This
        prevents the user from selecting or tabbing to the disabled editBox. If
        the editBox is the currently selected editBox we either select a different
        editBox or tell the Dialog Manager that there are no longer any editBox's
        by setting editField to -1.
    4) Enabling an editBox is simpler: its type is set back to editText and its
        text is selected (which resets editField). Both enable and disable
        invalidate the items rectangle so that the Dialog Manager and GreyFilter
        can redraw the item.

PROCEDURE EnableEditBox (dptr: DialogPtr; item: INTEGER; enable: BOOLEAN);
    VAR
        type : INTEGER;
        new  : INTEGER;
        data : HANDLE;
        box  : Rect;
        list : GreyHand;
        peek : DialogPeek;
        sPort: GrafPtr;
BEGIN
    GetPort(sPort);
    SetPort(dptr);
    peek := DialogPeek(dptr);
    list := GetWRefCon(dptr);
    IF list = NIL THEN                        (* create the array *)
        list := NewHandleClear(LONG(peek^.items^^)+1);
        SetWRefCon(dptr, list);
    END;
    GetDItem(dptr, item, type, data, box);    (* get the item type *)
    type := And(type, $7F);                   (* remove itemDisable flag *)
    IF (enable = FALSE) AND (type = editText) THEN
        SetDItem(dptr, item, statText+itemDisable, data, box);
        IF peek^.editField = item-1 THEN      (* is it the selected editBox? *)
            new := GetAnotherEditBox(dptr, item);
            IF item > 0 THEN
                SelIText(dptr, new, 0, 20);   (* select a different editBox *)
            ELSE
                SelIText(dptr, item, 0, 0);
                peek^.editField := -1;        (* there are no more editBox's! *)
            END;
        END;
        InvalRect(box);
        list^^[item] := TRUE;
    ELSIF enable AND list^^[item] THEN
        SetDItem(dptr, item, editText, data, box);
        SelIText(dptr, item, 0, 20);
        InvalRect(box);
        list^^[item] := FALSE;
    END;
    SetPort(sPort);
END EnableEditBox;

    GreyFilter calls the below procedure to grey out the text in a disabled
editBox. GetBounds is a utility procedure I wrote to get the bounds for
a dialog item. You can just as easily use GetDItem.

PROCEDURE GreyEditBox (dptr: DialogPtr; item: INTEGER);
    VAR
        box  : Rect;
        sPen : PenState;
        sPort: GrafPtr;
BEGIN
    GetPort(sPort);
    SetPort(dptr);
    GetPenState(sPen);
    box := GetBounds(dptr, item);
    InsetRect(box, -3, -3);        (* grey out the text *)
    PenPat(gray);
    PenMode(patBic);
    PaintRect(box);
    PenPat(black);                    (* draw the frame *)
    PenMode(patCopy);
    FrameRect(box);
    SetPenState(sPen);
    SetPort(sPort);
END GreyEditBox;

    All of my dialogs use a filter proc called DefaultFilter. If the dialog
needs to do some extra filtering it uses a different filter proc that first
calls DefaultFilter. GreyFilter is no exception: it calls DefaultFilter and
takes action only when DefaultFilter returns FALSE.
    The DefaultFilter is used to keep my dialogs consistent: Return/Enter always
work like a click on the OK button, and Escape/Tilde work like a click on the
Cancel button. Even more important, DefaultFilter updates the windows in my
application. If this isn't done its possible that applications in the background
will get no time while the dialog is up (see TechNote 304 for details).

PROCEDURE DefaultFilter (dptr: DialogPtr; VAR Event: EventRecord;
                                 VAR item: INTEGER): BOOLEAN;
    VAR
        ch, key: CHAR;
        wptr   : WindowPtr;
        control: ControlHandle;
        button : INTEGER;
        handled: BOOLEAN;
BEGIN
    handled := FALSE;
    IF Event.what = keyDown THEN
        ch := Event.msgChars[3];
        key := Event.msgChars[2];
        IF (key = ReturnKey) OR (key = EnterKey) THEN
            button := 1;
            handled := TRUE;
        ELSIF (key = TildeKey) OR (key = EscapeKey) THEN
            button := 2;
            handled := TRUE;
        ELSIF (cmd IN Event.modiFlags) AND (ch = '.') THEN
            button := 2;
            handled := TRUE;
        END;
        IF handled THEN                    (* make sure the button is enabled *)
            control := GetControl(dptr, button);
            IF control^^.contrlHilite = 0 THEN item := button END;
        END;
    ELSIF Event.what = updateEvt THEN
        wptr := Event.message;
        IF wptr <> dptr THEN
            WindEvent(Event);                        (* update my windows *)
        END;
    END;
    RETURN handled;
END DefaultFilter;

   The GreyFilter takes care of greying out all of the disabled editBox's. This
is a simple matter except for one minor detail: filter procs are called before
the Dialog Manager takes any action. So, it's not sufficient to just grey out
the editBox when we get an updateEvt. What we would have to do is first draw
the text in the editBx, grey it out, and then validate the editBox so the
Dialog Manager doesn't overwrite all of our work.
   The GreyFilter procedure takes a simpler approach. Update events are handled
normally by the Dialog Manager, but when an update event occurs GreyFilter adds
a special key to the Event queue to signal that an update occured. After the
Dialog Manager processes the update event it will call GreyFilter again with
the special key so that the editBox's may be greyed out.

PROCEDURE GreyFilter (dptr: DialogPtr; VAR Event: EventRecord;
                             VAR item: INTEGER): BOOLEAN;
    VAR
        list   : GreyHand;
        peek   : DialogPeek;
        index  : INTEGER;
        handled: BOOLEAN;
        err    : OSErr;
BEGIN
    handled := DefaultFilter(dptr, Event, item);
    IF NOT handled THEN
        IF Event.what = updateEvt THEN
            err := PostEvent(keyDown, 0);
        ELSIF Event.what = keyDown THEN
            IF LoWord(Event.message) = 0 THEN
                list := GetWRefCon(dptr);
                peek := DialogPeek(dptr);
                IF list <> NIL THEN
                    FOR index := 1 TO INT(peek^.items^^)+1 DO
                        IF list^^[index] THEN GreyEditBox(dptr, index) END;
                    END;
                END;
                handled := TRUE;
            END;
        END;
    END;
    RETURN handled;
END GreyFilter;

  --Jesse Jones

[e-mail]

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

From: [e-mail] (Rolf Maag)
Subject: setwindowpic
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Thu, 21 Jan 1993 14:59:25 GMT

Hi there...

i have some questions about getwindowpic and setwindowpic.

so far, i have done all my updating the 'old fashioned' way,
using update events...
now, with my latest application redrawing would be awfully complicated...

does the system all the updating when a window picture is set?

and when i draw into the window, is the window picture updated automatically?

if anybody could send me some sample code showing me how to use
getwindowpic and setwindowpic, i'd be very happy.

thanx and regards Rolf


+++++++++++++++++++++++++++

From: [e-mail] (Brian Stern; COMB)
Date: 22 Jan 93 16:33:00 GMT
Organization: University of Maryland, Center of Marine Biotechnology

In article <[e-mail]>, [e-mail] (Rolf Maag) writes...
>Hi there...
>
>i have some questions about getwindowpic and setwindowpic.
>
>
I use the following code in my initialization unit to put up a
splash screen:
var
  aPicHand: PicHandle;
  PicWind: WindowPtr;
  PicWinRect: Rect;
  TempBool: Boolean;

{Read in the picture and display it}
  aPicHand := PicHandle(GetResource('PICT', 128));{Read in the picture}
  PicWind := NewWindow(nil, PicWinRect, '', True, altDBoxProc, WindowPtr(-1),False,0);

 SetWindowPic(PicWind, aPicHand);{Insert the picture into the window}
  TempBool := CheckUpdate(Event);{Make the win mgr draw the window pic}

It normally isn't necessary to call CheckUpdate to draw a picture
in a window but this example draws it immediately. A picture
inserted into the windowPic field of a window record will be
drawn the next time a call is made to WaitNextEvent. What actually
happens is that if there are no other events in the event queue of
a higher priority than an update event, WNE calls CheckUpdate.
CheckUpdate then walks the window list from front to back looking
for visible windows with non-null update regions. If it finds one
that also has a picture associated with it, it draws the picture
in the window. It then continues until it finds a window with a
non-null update region and no picture. It then returns an update
event for that window, which is processed by your program in
the usual way. Note that you will never receive an update event
for a window with a non-null windowPic field. If you insert a
picture into a window with SetWindowPic and later change it and
want it to be redrawn you can do an InvalRect
(theWindow^.portrect). The picture will be redrawn the next time
thru your event loop if no other events are pending. Update events
have the lowest priority except for null events so mouse clicks,
key presses will be processed first.

Good Luck,

Brian Stern
[e-mail]

__________________________________________________________________
According to a software licensing notice:
All trademarks are held by their respective owners.
__________________________________________________________________
>

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

From: [e-mail] (Mark Anderson)
Subject: Modifying width of PopUp menus in System 7.1
Date: 19 Jan 93 02:53:19 GMT
Organization: CS Dept, Oregon State University

I am writing a program and have a dialog box that contains three popup menus.
I am changing the font used by the popups to Geneva 9 via mucking around with
some low-memory globals.  Anyway, the popup rectangles are wider than the menus
they are linked to, so I wanted to widen the menus before they are displayed.
What I did was check to see if the (**popMenu).menuWidth field was less than
the width of the appropriate rectangle.  If it was then I just set the menuWidth
field to equal the width of the rectangle.  This is done right before my call
to PopUpMenuSelect.  Basically it works fine on my SE running either System 6.08
or System 7.01, but on my neighbors LC running 7.1 the menu widths aren't
being modified, they are just wide enough to contain that menus items.  My
question is whether or not System 7.1 does anything different with regard to
pop-up menus, has PopUpMenuSelect been patched to do a CalcMenuSize?  Any help
would be appreciated.

                            - Mark J. Anderson



+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 19 Jan 93 10:29:34 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail]
(Mark Anderson) wrote:
>
> I am writing a program and have a dialog box that contains three popup menus.
> I am changing the font used by the popups to Geneva 9 via mucking around with
> some low-memory globals.  Anyway, the popup rectangles are wider than the menus
> they are linked to, so I wanted to widen the menus before they are displayed.
> What I did was check to see if the (**popMenu).menuWidth field was less than
> the width of the appropriate rectangle.  If it was then I just set the menuWidth
> field to equal the width of the rectangle.  This is done right before my call
> to PopUpMenuSelect.  Basically it works fine on my SE running either System 6.08
> or System 7.01, but on my neighbors LC running 7.1 the menu widths aren't
> being modified, they are just wide enough to contain that menus items.  My
> question is whether or not System 7.1 does anything different with regard to
> pop-up menus, has PopUpMenuSelect been patched to do a CalcMenuSize?  Any help
> would be appreciated.
>
>                             - Mark J. Anderson

Here's some code to do what you want.  I'm right in the middle of working
on this,
so I can't say it's 100% correct, but I'm pretty sure it's close.  It will
give
you all the essential concepts, anyway.

Tim Dierks
MacDTS, but I speak for myself

- --- cut here -- 8< ------

// type of a pointer to CalcMenuSize
typedef pascal void (*CalcMenuSizeProc)(MenuHandle theMenu);
static pascal void  CalcMenuSizePatch(MenuHandle theMenu);

// Record to use to communicate with the patch to CalcMenuSize
typedef struct
{   CalcMenuSizeProc    oldCMS;         // Address of the original
CalcMenuSize()
    MenuHandle          theMenu;        // Menu to set the width of
    short               width;          // The width to set it to
} CMSCommRecord;

// The record to communicate with the patch.  Making this a global is
// not the ideal solution for this communication, but should work for
// this particular application.  I would use a better solution, but
// the global is adequate and clearer.

CMSCommRecord       gCMSParms;

// Call just like PopUpMenuSelect, only you can set the font, size, and
width of the popup menu.
//  Pass 0 for font, size, or width to use the defaults.
long
PopUpMenuSelectWithFontAndWidth(MenuHandle menu,short top,short left,short
popUpItem,short font,short size,short width)
{   long                menuChoice;                     // Stores the
chosen menu & item
    short               saveSysFontFam,saveSysFontSize; // Room for saving
the current system font and size
    GrafPtr             wMgrPort;                       // Pointer to the
window manager port
    CalcMenuSizeProc    oldCalcMenuSize;                // Address of the
old CalcMenuSize procedure

    // First, we'll clean up after buggy software.  A number of commercial
products
    // (word processors are most common) screw up the window manager port;
they leave the
    // txSize field set to 12.  It and the txFont field should always be
left set to 0;
    // this makes them the system font and size.  So first thing we do is
clean up
    // after these miscreants.

    GetWMgrPort(&wMgrPort);
    SetPort(wMgrPort);
    TextFont(0);
    TextSize(0);

    // Now, if we're going to change the font or the size, then we remember
the old
    // system font and size so they can be restored later

    if (font != 0 || size != 0)
    {   saveSysFontFam = *(short*)SysFontFam;
        saveSysFontSize = *(short*)SysFontSize;

        if (font != 0)
            *(short*)SysFontFam = font;
        if (size != 0)
            *(short*)SysFontSize = size;

        *(long*)LastSPExtra = -1;           // This forces the system to
recognize our changes
    }

    // Now we need to set the width.  Unfortunately, it's not as easy as
changing the
    // font and size; we need to patch CalcMenuSize so we can fake the
width of the menu
    if (width != 0)
    {   oldCalcMenuSize =
(CalcMenuSizeProc)NGetTrapAddress(0x148,ToolTrap);

        gCMSParms.oldCMS = oldCalcMenuSize;
        gCMSParms.theMenu = menu;
        gCMSParms.width = width;

        NSetTrapAddress((long)CalcMenuSizePatch,0x148,ToolTrap);

        // Now we should zero out the menu's stored width and height to
ensure that
        // its size will be recalculated

        (**menu).menuWidth = 0;
        (**menu).menuHeight = 0;
    }

    menuChoice = PopUpMenuSelect(menu,top,left,popUpItem);

    // Now we restore the original CalcMenuSize if we changed it
    if (width != 0)
        NSetTrapAddress((long)oldCalcMenuSize,0x148,ToolTrap);

    // Now we restore the original font and size to their places
    // if we changed them
    if (font != 0 || size != 0)
    {   *(short*)SysFontFam = saveSysFontFam;
        *(short*)SysFontSize = saveSysFontSize;
        *(long*)LastSPExtra = -1;
    }

    // return the chosen menu & item
    return menuChoice;
}

// This is the patch to CalcMenuSize; first, we call the original
// to calculate the size.  If the menu being calculated is ours,
// we then change the width to our stored width.  Note that this
// is a tail patch; while still frowned upon, these are not as
// bad as they used to be, and it's really the best way to
// accomplish our task.
//
// Our use of a global to store the original CalcMenuSize and
// other data implies we'll be sure that A5 hasn't been changed;
// we can be fairly certain this is true in this particular
// case.

static pascal void
CalcMenuSizePatch(MenuHandle theMenu)
{
    gCMSParms.oldCMS(theMenu);          // Call the original
CalcMenuSize();

    if (theMenu == gCMSParms.theMenu)   // If it's our menu, fix up the
width
        (**theMenu).menuWidth = gCMSParms.width;
}

+++++++++++++++++++++++++++

From: [e-mail] (Michael S Shields)
Date: 22 Jan 93 08:18:47 GMT
Organization: University of Utah Computer Science

In article <[e-mail]> [e-mail] (Tim Dierks, software saboteur) writes:
>
>Here's some code to do what you want.  I'm right in the middle of working
>on this,
>so I can't say it's 100% correct, but I'm pretty sure it's close.  It will
>give
>you all the essential concepts, anyway.
>
>Tim Dierks
>MacDTS, but I speak for myself
>

[some code deleted]

>    // First, we'll clean up after buggy software.  A number of commercial
>products
>    // (word processors are most common) screw up the window manager port;
>they leave the
>    // txSize field set to 12.  It and the txFont field should always be
>left set to 0;
>    // this makes them the system font and size.  So first thing we do is
>clean up
>    // after these miscreants.
>
>    GetWMgrPort(&wMgrPort);
>    SetPort(wMgrPort);
>    TextFont(0);
>    TextSize(0);
>
[more code deleted]

This section I have a question about. I found out the other day that the system
software for international use(ie. Kanji) doesn't use 0 as the system font.
If I set the SysFontFam global to 0 the menu and titlebar text showed up in
Chicago not Osaka(is this the correct name?). Now does TextFont and TextFace
have the intelligence to use the correct font or does it blindly use Chicago?
This was using Kanji 7.1 on a IIsi.

Mike Shields
[e-mail]

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

From: [e-mail] (Jeff Berkowitz)
Subject: Finding Application to Launch
Date: 19 Jan 93 07:22:56 GMT
Organization: Sequent Computer Systems, Inc.

I'm writing an application that will at times launch a word processor.
I'd like the user to be able to select the word processor so that (at
least in theory) my app will work with any WP.

It seems the right way to store the "name" of the WP is to store
its creator.  This could be kept in a pref.

When time comes to launch, if the pref hasn't been set then present
the user with a dialog resembling standard file so they can select
the WP; stash the creator away in the pref.

Now having the creator, look it up in the desktop database using
PBDTGetAPPL().  Now you have the dirID and name so you can build
up the launchAppSpec.  Yes?

One thing I don't understand: the desktop database is per-volume.
The active volume might not be the right place to look - it might
be a floppy with no apps, for example.  So do I have to iterate
the steps above on all mounted volumes?  And then what do I do if
I find two volumes that contain an APPL with the correct creator...
pick the most recent?  Is this what the Finder does?

For that matter, how does one "iterate the mounted volumes?"  Call
GetVInfo() with incrementing drvNum's? ...IM-IV implies this won't
work in general (p93).

TIA,
- --
Jeff Berkowitz, Sequent Computer Systems   [e-mail]  uunet!sequent!jjb
 "The event horizon of a smoking hairy golfball is on the chip" - Jim Gray

+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 19 Jan 93 12:40:45 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <[e-mail]> [e-mail] (Jeff Berkowitz) writes:

>It seems the right way to store the "name" of the WP is to store
>its creator.  This could be kept in a pref.

You could also store an alias to the selected application for
quick access to file servers and the likes.

>Now having the creator, look it up in the desktop database using
>PBDTGetAPPL().  Now you have the dirID and name so you can build
>up the launchAppSpec.  Yes?

No, unless the application is available on a presently mounted
volume. You also have to iterate over all available volumes.

>For that matter, how does one "iterate the mounted volumes?"  Call
>GetVInfo() with incrementing drvNum's? ...IM-IV implies this won't

No, call PBHGetVInfo with the indexed volume mode. Look in
Inside Mac or Think Reference for how to do it.

What I do is I create an alias, and when I need the app, I
resolve the alias. If it cannot be resolved, I search all
mounted volumes using PBCatSearch for a file of type APPL
and creator <whatever>.

Cheers,

                        / h+
- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

  Clearly, most humans are not rational beings; they are rationalizing beings.
                     -- Mel Walker

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

From: [e-mail] (Dr Garry Willgoose: INTERNET [e-mail])
Subject: Slow drawing under System 7
Organization: University of Newcastle, AUSTRALIA
Date: Tue, 19 Jan 1993 11:25:29 GMT

I have a program that basically puts up on screen a huge number of filled
rectangles. Just a plain loop with relevamt QD commands and a call to
WaitNextEvent with wait time set to 0. Well this code has worked fine to ages
on a system 6 machine but when Imoved it recently to a Powerbook 170 running
S7 it runs really slow ... unless I keep moving the mouse around and then it
runs just like before. Actually this same behaviour is shown by another
part of the code where a series of line segments is drawn so its not a
function of the particular QD calls. The picture is being saved a PICT2 as the
pict is drawn.

Any ideas of where I might start to track down this problem? The program is all
in Pascal on MPW (both 3.2).

Garry Willgoose
Dept of Civil Eng
Uni of Newcastle
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Robert Mah)
Organization: PANIX Public Access Unix, NYC
Date: Tue, 19 Jan 1993 16:40:46 GMT

In <[e-mail]> [e-mail] (Dr Garry Willgoose: INTERNET [e-mail]) writes:


> Just a plain loop with relevamt QD commands and a call to WaitNextEvent
> with wait time set to 0. Well this code has worked fine to ages on a
> system 6 machine but when Imoved it recently to a Powerbook 170 running
> S7 it runs really slow ... unless I keep moving the mouse around and then
> it runs just like before.

Your comment about moving the mouse _may_ suggest that you take a look at
the mouseRgn parameter to WaitNextEvent.  Perhaps you're getting an excessive
amount of mouseMoved events?

Cheers,
Rob


- --
[----------------------------------------------------------------------]
[ Robert S. Mah   | Voice: 212-947-6507   | "Every day an adventure,   ]
[ One Step Beyond | EMail: [e-mail] |  every moment a challenge" ]
[----------------------------------------------------------------------]

+++++++++++++++++++++++++++

From: [e-mail] (Conrad Halling)
Organization: University of Chicago
Date: Thu, 21 Jan 1993 20:48:55 GMT

In article <[e-mail]>
  [e-mail]
  (Dr Garry Willgoose: INTERNET [e-mail]) writes:

>I have a program that basically puts up on screen a huge number of filled
>rectangles. Just a plain loop with relevant QD commands and a call to
>WaitNextEvent with wait time set to 0. Well this code has worked fine to ages
>on a system 6 machine but when I moved it recently to a Powerbook 170 running
>S7 it runs really slow ... unless I keep moving the mouse around and then it
>runs just like before. Actually this same behaviour is shown by another
>part of the code where a series of line segments is drawn so its not a
>function of the particular QD calls. The picture is being saved a PICT2 as the
>pict is drawn.

The PowerBook goes into resting (idling or processor cycling) mode when
certain activities are not occurring.  (One of the activities that prevents
resting is moving the mouse.)  This is what is causing your
program to slow down.  The net result is that PowerBook behaves as if
the processor were running at 1 MHz.

Read chapter 31 of Inside Macintosh Vol VI about the Power Manger.  Your
program needs to call Gestalt() to determine if the Power Manager is
present (p. 31-12).  (The Power Manager is present only for the Portable
and PowerBooks).  If the Power Manager is present, then call IdleUpdate()
(p. 31-19) each time through your event loop when you're doing something
significant.  If you have nothing to do on null events, then don't call
IdleUpdate(), and the PowerBook can go into rest mode, which is a good
thing for battery charging.
- --
Conrad Halling
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 19 Jan 93 12:46:27 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <[e-mail]> [e-mail] (Dr Garry Willgoose: INTERNET [e-mail]) writes:

>on a system 6 machine but when Imoved it recently to a Powerbook 170 running
>S7 it runs really slow ... unless I keep moving the mouse around and then it

>Any ideas of where I might start to track down this problem? The program is
>all in Pascal on MPW (both 3.2).



Start by reading the manual for your PowerBook 170. Yes,
the one that came with the computer, that still has the plastic
wrapping on it. It will tell you all about the "rest" mode of
a PowerBook, and how to turn it off using an option-click in
the "portable" control panel.

Cheers,

                        / h+
- --
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

  Clearly, most humans are not rational beings; they are rationalizing beings.
                     -- Mel Walker

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

From: [e-mail] (Carol Cantrell)
Subject: Color animation in After Dark...HELP!
Date: Thu, 21 Jan 1993 05:56:23 GMT
Organization: Colorado State University, Fort Collins, CO  80523

I'm writing an After Dark module that uses color table animation.  It copies
repeatedly some object from offscreen graphics worlds, some of which contain
colors to be animated, and some of which don't.  I want to copy the GWorlds to
the screen color index for color index--that is, color #1 in the GWorld is color
on the screen, etc.  The obvious way to do this is to OR the ctFlags field
with $4000; however, this copies index numbers from the GWorld to index numbers
in the current PALETTE.  After Dark doesn't draw into a WINDOW, and therefore
DOESN'T HAVE A PALETTE!!!   Is there any way to do this?  Help!

 Paul Cantrell
 [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 21 Jan 1993 20:05:41 GMT

[e-mail] (Carol Cantrell) writes:
>I'm writing an After Dark module that uses color table animation. ...
>I want to copy the GWorlds to the screen color index for color index--
>that is, color #1 in the GWorld is color [#1] on the screen, etc.
>The obvious way to do this is to OR the ctFlags field with $4000;

Not _that_ obvious;  it's hidden pretty well in IM VI, actually.  :-)

>however, this copies index numbers from the GWorld to index numbers
>in the current PALETTE.  After Dark doesn't draw into a WINDOW, and therefore
>DOESN'T HAVE A PALETTE!!!   Is there any way to do this?  Help!

Yep, there are three ways to get the Color Indices You Want up onto the
screen:
    (1) Set bit 14 in ctFlags;
    (2) Make the ctSeeds equal;
    (3) Write directly to the screen.

(1) won't work for you, as you say, because AD opens a port not a
palette.  (Actually, does it even do that?  Someone said it uses
SetStdProcs() to redirect QD calls to its own nefarious ends.  I don't
even want to think about that.)

(2) is probably your best bet in this case.  If the ctSeed in your
source pixmap's color table is equal to the ctSeed in your dest pixmap's
color table, CopyBits will take this to mean that the color tables are
in fact equal.  It will not run through them and check.  Consequently,
it will just copy the pixel values straight across, which has the effect
you want.  (And, as a side dish, it's also the fastest possible way that
CopyBits can operate.)

You can set the ctSeeds yourself, manually, if you like.  Normally,
that's not a good idea, but After Dark is such a snuggly, hand-holding
environment to work in, that I won't even give you the usual "now don't
do this" warning.  All you gotta do is drop a 'clut' in your module with
the appropriate resource ID, set a few flags, maybe check the screen
depth yourself, and you're guaranteed to have the screen you want, with
the colors you want.  So--do the checks, copy the screen's pixmap's
pmTable's ctSeed into your GWorld's pixmap's pmTable's ctSeed, and
CopyBits to your heart's content.

Alternatively, you can build a GWorld using the screen's pmTable.  But
I'm not too familiar with GWorlds, so you're on your own there.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "We enjoy a patent portfolio second to none in the computer industry,
  with some 30,000 patents worldwide and more than 9,000 in the U.S. alone,
  and growing."                      - An IBM advertisement

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

End of C.S.M.P. Digest
**********************