Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-076

Internet Message Format | 1995-06-07 | 128.0 KB | [TEXT/R*ch]

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-076
To: [e-mail]
Date: Fri, 23 Dec 1994 12:22:34 +0100 (MET)
Mime-Version: 1.0
Reply-To: [e-mail]
X-Sequence: 82

C.S.M.P. Digest             Fri, 23 Dec 94       Volume 3 : Issue 76

Today's Topics:

        AEInstallEventHandler Problem
        How do I keep my program from coming to the foregroud for drags?!?!
        How do you use the mouse as a relative motion device?
        How to convert a Picture to a PixPat?
        Info on BlockMoveData ?
        Installer advice please?
        Mac FAQ now available as HTML using WWW!
        PowerPlant vs. MacApp - opinions ?
        QuickDraw GX Thread Safe?
        [Q] Need help with SetGWorld.
        static RoutineDescriptors



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet 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 may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

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
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks 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 digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


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

>From [e-mail] (Jeff Corr)
Subject: AEInstallEventHandler Problem
Date: 3 Dec 1994 21:38:20 GMT
Organization: Arizona Macintosh Users Group

I am unable to compile a program in part because I do not have
documentation (i.e. the appropriate volume of Inside Macintosh) for the
AEInstallEventHandler function although I did find the declaration for
AEInstallEventHandler in the Types.h file.  I have not found a #define for
the AEEventHandlerUPP type that is used in the declaration of
AEInstallEventHandler in any of the header files that I included and
perhaps this is contributing to this problem.  The relevant information and
code follow.


These fragments of code are from the Macintosh C Primer by Dave Mark and
Cartwright Reed.


/*****  EventTracker  *****/

#include <AppleEvents.h>
#include <GestaltEqu.h>
#include <Limits.h>
.
. (irrelevant declarations omitted)
.
/* declaration for the EventHandler function follows */

pascal  OSErr   DoOpenApp (AppleEvent theAppleEvent,  AppleEvent reply,  long
refCon);
.
. (more irrelevant declarations and code omitted)
.

/*****  EventInit  *****/

void EventInit (void)
{
   OSErr        err;    /* Straight from the book... I tried putting the pascal
identifier before OSErr but this did not help */
.
.
.
   err = AEInstallEventHandler (kCoreEventClass, kAEOpenApplication,
DoOpenApp, 0L, false);
   if (err != noErr)  DrawEventString ("\pkAEOpenApplication Apple Event
not available!");
.
. (no more relevant code)
.

>From the codeWarrior message window:


%% Error   : declaration syntax error
   EventTracker.c line 110   err =
AEInstallEventHandler(kCoreEventClass,kAEOpenApplication, DoOpenApp, 0L,
false);

note: I included MacOS.Lib in the project file.


The declaration that I found in Types.h:

extern pascal OSErr AEInstallEventHandler(AEEventClass theEventClass,
AEEventID theEventID, AEEventHandlerUPP handler, long handlerRefcon,
Boolean isSysHandler)
 THREEWORDINLINE(0x303C, 0x091F, 0xA816)

I have not found the declaration for AEEventHandlerUPP (the third parameter
that is passed in the above declaration) in any of the header files.

Apologies if this is too trivial a matter for this group.  I am very much a
beginner at this but I can assure you that I have spent alot of time trying
to figure this out. I plan on getting the CD version of Inside Macintosh as
soon as santa brings me a CD-ROM.

Regards,

Jeff





--
This (code) warrior is still in boot camp.

Jeff Corr
[e-mail]   Arizona Macintosh Users Group

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

>From [e-mail] (Andreas Pizsa)
Date: 06 Dec 1994 00:55:10 GMT
Organization: The Personal Online Source

> I have not found a #define for
>the AEEventHandlerUPP type that is used in the declaration of
>AEInstallEventHandler in any of the header files that I included and
>perhaps this is contributing to this problem.  The relevant information and
>code follow.

Here is some code that does what you need; note the NewAEEventHandlerProc
function, which actually is a macro on 68k-Macs.

static EventListEntry theEventList[]={
        { kAEDBSuite,kAEGetData,(ProcPtr)GetDataEvent },
        { kCoreEventClass,kAEQuitApplication,(ProcPtr)QuitApplication},
        { kFirstAccessSuite,kGetStatusEvent,(ProcPtr)GetStatusEvent},
        { kFirstAccessSuite,kAEFindFormEvent,(ProcPtr)AEGetFormHandler}
};

        /*
        ** Install the AppleEvent handlers
        **
        ** We*re using the Universal Headers, so NewAEEventHandlerProc is called
        ** It*s not necessary to call DisposeRoutineDescriptor, since this is done
        ** automatically when the application exits & the heap is cleared
        */

        for(i=0;i<sizeof(theEventList)/sizeof(theEventList[0]);++i){
                myErr=AEInstallEventHandler(
                        theEventList[i].theClass,
                        theEventList[i].theID,
                        NewAEEventHandlerProc(theEventList[i].theProc),
                        (long)myGlobalsH,false
                        );
                if(myErr){
                        #ifdef DEBUG
                                DebugStr("\pError installing AppleEvent Handler");
                        #endif
                        SysBeep(0);
                        goto err;
                }
        }


Hope this helps!

Andreas
FirstAccess Developer
Networx GmbH

 --------------------------------------------------------
 sent via  m a g n e t / [phone] / [e-mail]
 --------------------------------------------------------


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

>From Jens Alfke <[e-mail]>
Date: Thu, 8 Dec 1994 20:40:42 GMT
Organization: Apple Computer

Jeff Corr, [e-mail] writes:
> I am unable to compile a program in part because I do not have
> documentation (i.e. the appropriate volume of Inside Macintosh) for the
> AEInstallEventHandler function although I did find the declaration for
> AEInstallEventHandler in the Types.h file.

That's funny, the declaration should be in AppleEvents.h along with all the
other AE stuff.
Assuming you are compiling for 68k, just cast the address of the function to
an AEEventHandlerUPP:

AEInstallEventHandler(kCoreEventClass,kAEOpenApplication,
    (AEEventHandlerUPP)&DoOpenApp, 0L,false);

If you're compiling for PPC you need to make up a routine descriptor; better
wait for Santa to bring your Inside Mac, as this stuff gets a bit trickier.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

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

>From [e-mail]
Subject: How do I keep my program from coming to the foregroud for drags?!?!
Date: 18 Nov 1994 14:43:59 -0500
Organization: University of Michigan Archives

OK, I'm implementing the dragmanager into my program. Everything's great.
Other programs get my data, yea. (I don't accept drags because it's a
read-only document) HOWEVER, I seem to have a problem when my app is
in the background and someone tries to drag hilited text out into the
foreground. According to the HIG, and the way the Finder and Scrapbook
behave, my app should NOT come to the foreground, the drag should just
move from the background to the foreground. Now note that the Finder and
the Scrapbook are the only two apps that I've found that do this properly;
SimpleText, Zterm, and even StickyNotes (and I think the Notepad too) all
botch it up and come to the front.

So the question is, how to keep my app from rising to the front when I
don't want it to. I checked the SIZE resources, and both had on front
clicks. So I turned them on in my app, and nothing new happens. <sigh>
I start going through and checking on the events I'm getting.

Unfortunatly, I seem to be brought to the front before a resume evt (my
window comes to the front that is), then I get my resume evt, then I get
my mousedown. This annoys me to no end, as I'd like to make it right,
even though most apps that I've seen don't bother (oh, the DragText
example doesn't do it right either...). The only thing I could think of
was my SIZE resource, but the three that I could see making a difference
seem to be the same as the Finder/Scrapbook... (acceptSuspendResume,
doesActivateOnSuspendResume, and getFrontClicks... all true)

Please help! Thx!
--
| Rob Hagopian.           | FINGER me! (01/18) | Moon Over Miami |   Four   |
| [e-mail]  +--------------------+-----------------+ lines? I |
| [e-mail]. |GC 1.0.1: GU d -p+(-) c++++ !l u++ e/+| only get |
|          itd.umich.edu  |       m/- s/- !n h f? g+ w+ t-- r- y?|   four   |

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

>From [e-mail] (Bo Lindbergh)
Date: 19 Nov 1994 08:40:35 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <3aj05v$[e-mail]> [e-mail] writes:
) OK, I'm implementing the dragmanager into my program. Everything's great.
) Other programs get my data, yea. (I don't accept drags because it's a
) read-only document) HOWEVER, I seem to have a problem when my app is
) in the background and someone tries to drag hilited text out into the
) foreground. According to the HIG, and the way the Finder and Scrapbook
) behave, my app should NOT come to the foreground, the drag should just
) move from the background to the foreground. Now note that the Finder and
) the Scrapbook are the only two apps that I've found that do this properly;
) SimpleText, Zterm, and even StickyNotes (and I think the Notepad too) all
) botch it up and come to the front.

I could tell you how to do this, but then Apple would have both of us shot.
This is yet another thing that only system programs like the Finder are
allowed to do.


/Bo Lindbergh

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

>From [e-mail] (Rob Hagopian)
Date: 19 Nov 1994 05:24:27 -0500
Organization: University of Michigan Archives

In article <3akdm3$[e-mail]>,
Bo Lindbergh <[e-mail]> wrote:
:In article <3aj05v$[e-mail]> [e-mail] writes:
:) OK, I'm implementing the dragmanager into my program. Everything's great.
:) Other programs get my data, yea. (I don't accept drags because it's a
:) read-only document) HOWEVER, I seem to have a problem when my app is
:) in the background and someone tries to drag hilited text out into the
:) foreground. According to the HIG, and the way the Finder and Scrapbook
:) behave, my app should NOT come to the foreground, the drag should just
:) move from the background to the foreground. Now note that the Finder and
:) the Scrapbook are the only two apps that I've found that do this properly;
:) SimpleText, Zterm, and even StickyNotes (and I think the Notepad too) all
:) botch it up and come to the front.
:
:I could tell you how to do this, but then Apple would have both of us shot.
:This is yet another thing that only system programs like the Finder are
:allowed to do.

Any hints? I've traced through them and they don't even go through a call
--
| Rob Hagopian.           | FINGER me! (01/18) | Moon Over Miami |   Four   |
| [e-mail]  +--------------------+-----------------+ lines? I |
| [e-mail]. |GC 1.0.1: GU d -p+(-) c++++ !l u++ e/+| only get |
|          itd.umich.edu  |       m/- s/- !n h f? g+ w+ t-- r- y?|   four   |

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

>From [e-mail] (Jon W{tte)
Date: Sun, 20 Nov 1994 16:42:32 +0100
Organization: The Conspiracy

In article <3akjor$[e-mail]>,
[e-mail] (Rob Hagopian) wrote:

>:I could tell you how to do this, but then Apple would have both of us shot.
>:This is yet another thing that only system programs like the Finder are
>:allowed to do.

>Any hints? I've traced through them and they don't even go through a call

There is this magic system call you have to make to register
that you want clicks without a switchin.

There *WAS* a gestalt bit to test for this call, but in the
very latest Universal Headers, that bit has been conveniently
"forgotten".

Because of that, I don't think it's good idea to actually use
the stuff if you reverse-engineer it, but on the other hand,
it's functionality that Apple should *really* provide to
developers.

Cheers,

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

   Cookie Jar: Vanilla Yoghurt with Crushed Oreos.


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

>From [e-mail] (Rob Hagopian)
Date: 21 Nov 1994 00:11:26 -0500
Organization: University of Michigan Archives

In article <[e-mail]>,
Jon W{tte <[e-mail]> wrote:
>There is this magic system call you have to make to register
>that you want clicks without a switchin.
>
>There *WAS* a gestalt bit to test for this call, but in the
>very latest Universal Headers, that bit has been conveniently
>"forgotten".

Really? It's still in the CW/4 Univ Headers... I believe it's
bit 10... :-)

>Because of that, I don't think it's good idea to actually use
>the stuff if you reverse-engineer it, but on the other hand,
>it's functionality that Apple should *really* provide to
>developers.

I decided not to persue it further after I found out it was
not kosher... Well, at least for anything I'll be releasing :-)
--
| Rob Hagopian.           | FINGER me! (01/18) | Moon Over Miami |   Four   |
| [e-mail]  +--------------------+-----------------+ lines? I |
| [e-mail]. |GC 1.0.1: GU d -p+(-) c++++ !l u++ e/+| only get |
|          itd.umich.edu  |       m/- s/- !n h f? g+ w+ t-- r- y?|   four   |

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

>From [e-mail] (Scott Lindsey)
Date: Thu, 01 Dec 1994 20:30:05 -0800
Organization: Claris Corp., Vancouver WA

In article <3akjor$[e-mail]>,
[e-mail] (Rob Hagopian) wrote:

> In article <3akdm3$[e-mail]>,
> Bo Lindbergh <[e-mail]> wrote:
> :In article <3aj05v$[e-mail]>
[e-mail] writes:
> :) OK, I'm implementing the dragmanager into my program. Everything's great.
> :) Other programs get my data, yea. (I don't accept drags because it's a
> :) read-only document) HOWEVER, I seem to have a problem when my app is
> :) in the background and someone tries to drag hilited text out into the
> :) foreground. According to the HIG, and the way the Finder and Scrapbook
> :) behave, my app should NOT come to the foreground, the drag should just
> :) move from the background to the foreground. Now note that the Finder and
> :) the Scrapbook are the only two apps that I've found that do this properly;
> :) SimpleText, Zterm, and even StickyNotes (and I think the Notepad too) all
> :) botch it up and come to the front.
> :
> :I could tell you how to do this, but then Apple would have both of us shot.
> :This is yet another thing that only system programs like the Finder are
> :allowed to do.
>
> Any hints? I've traced through them and they don't even go through a call

Well, here's a hint: Scrapbook registers some sort of magic callback via
_OSDispatch with a selector of $55.  This routine gets called by the
system when there's a click in the non-active application, before the
application's call to WNE returns.  This is where the drag (if there is
one) gets initiated.  As it's been pointed out before, Apple hasn't
documented this, and while there's a certain perverse pleasure in figuring
out how things work (like the layer manager), using undocumented calls can
hurt you when the system changes (like the layer manager).

While Apple hasn't documented this, it might be worth noting that the
Scrapbook application (no, it's not a DA anymore) was written by a third
party, Light Software, for whom it was either documented or who reverse
engineered it with the expectation that the Scrapbook is system software
and doesn't necessarily have to be compatible with future system software
(since it can be revved).

--
Scott Lindsey <[e-mail]>

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

>From [e-mail] (Greg Ewing)
Subject: How do you use the mouse as a relative motion device?
Date: 28 Nov 1994 00:15:33 GMT
Organization: University of Canterbury, Christchurch, New Zealand


Various games, such as Oxyd and Wolf 3D, use the
mouse as a relative rather than absolute motion
device. That is, moving the mouse causes some
corresponding motion in the game, but there is
no limit of the mouse hitting the edge of the
screen.

How is this accomplished? Two approaches I
can think of are:

(1) Somehow intercept the motion signals coming
from the mouse at a lower level than the usual
event mechanism.

(2) Periodically reset the pointer location to
the middle of the screen.

There doesn't seem to be any official way of
doing either of these. Does anyone know how
the trick is usually done, and what is the
least non-portable way of going about it?

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From [e-mail] (Ingemar Ragnemalm)
Date: 28 Nov 1994 10:31:52 GMT
Organization: (none)

[e-mail] (Greg Ewing) writes:


>Various games, such as Oxyd and Wolf 3D, use the
>mouse as a relative rather than absolute motion
>device. That is, moving the mouse causes some
>corresponding motion in the game, but there is
>no limit of the mouse hitting the edge of the
>screen.

>How is this accomplished? Two approaches I
>can think of are:

>(1) Somehow intercept the motion signals coming
>from the mouse at a lower level than the usual
>event mechanism.

"Somehow" is the word. I can't see any doumentation that tells us how
to go this way.

>(2) Periodically reset the pointer location to
>the middle of the screen.

This is what I did in HeartQuest. I'm not sure if it's the most portable
one (though it seems to work on all present Macs - anyone know if it works
with A/UX?) but it's pretty easy. The drawback is that I have to deped
on a global that might go away some time.

>There doesn't seem to be any official way of
>doing either of these. Does anyone know how
>the trick is usually done, and what is the
>least non-portable way of going about it?

It would really be nice if Apple could tell us what we should do when we
*have* to do it. How about a mechanism that will ONLY work when the cursor
is hidden? Then we won't break the interface rules as badly - if at all!

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

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

>From [e-mail] (CasadyGree)
Date: 28 Nov 1994 10:20:32 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <3bb7f5$[e-mail]>,
[e-mail] (Greg Ewing) writes:

>>>
Various games, such as Oxyd and Wolf 3D, use the
mouse as a relative rather than absolute motion
device.
...
(2) Periodically reset the pointer location to
the middle of the screen.
>>>

That's right.  Glider 4.0 did this in "joystick" mode (for the old Kraft
QuickStick) - every pass through the game check the mouse location from
the center - then center it (this also foiled AfterDark's auto-sleep
feature as well).

There's a funtion floating around called SetMouse().  It can be found, for
example, in the UMPG (Usenet Macintosh Programming Guide) available at
reputable FTP sites.  Download the text - there are a lot of other useful
(and some dated) FAQ's in it.

john calhoun
([e-mail])

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

>From [e-mail] (Ingemar Ragnemalm)
Date: 28 Nov 1994 16:51:56 GMT
Organization: (none)

[e-mail] (CasadyGree) writes:
>That's right.  Glider 4.0 did this in "joystick" mode (for the old Kraft
>QuickStick) - every pass through the game check the mouse location from
>the center - then center it (this also foiled AfterDark's auto-sleep
>feature as well).

Any idea on how compatible it is?

>There's a funtion floating around called SetMouse().  It can be found, for
>example, in the UMPG (Usenet Macintosh Programming Guide) available at
>reputable FTP sites.  Download the text - there are a lot of other useful
>(and some dated) FAQ's in it.

And here is one version of it:

procedure SetMouse (where: point);
        var
                LowGlob: integer;
                LowMem: ptr;
                PointPtr: ^point;
        const
{some dangerous low-memory-global equates}
                MTemp = $828;        {point}
                RawMouse = $82c;     {point}
                CrsrNew = $8ce;      {byte}
        begin
                LocalToGlobal(where);             {Get ready to restore old mouse position}
                LowMem := pointer(RawMouse);      {point to low memory}
                PointPtr := @LowMem^;             {treat it as a point}
                PointPtr^ := where;               {store saved mouse position into it}
                LowMem := pointer(MTemp);         {point to low memory}
                PointPtr := @LowMem^;             {treat it as a point}
                PointPtr^ := where;               {store saved mouse position into it}
                LowMem := pointer(CrsrNew);
                LowMem^ := $ffff;                 {both CrsrNew & CrsrCouple}
        end;       {SetMouse}

This is what I use in SAT/HeartQuest/Slime Invaders. I didn't write it; it's
taken from UMPG or from a post here. Sorry for the bad capitalization; I
never bothered to fix that.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

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

>From [e-mail] (Greg Ewing)
Date: 29 Nov 1994 01:00:22 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <3bcbio$[e-mail]>, [e-mail] (Ingemar Ragnemalm) writes:
|>
|> It would really be nice if Apple could tell us what we should do when we
|> *have* to do it.

What would be really nice for this problem would
be to receive "raw mouse moved" events. These would
be disabled by default, but when requested, would
tell you every time the mouse was moved (regardless
of whether the pointer is at the edge of the screen
or not) and how much it has moved since the last
such event.

I wonder if it would be possible to create a
custom ADB device driver which does this?
Is there any information around about how to
write ADB drivers? If the ADB interface is stable
enough, it might allow us to create a "relative
mouse extension" that would be more reliable
than messing with low memory globals.

|> Ingemar Ragnemalm, PhD
|> E-mail address: [e-mail] or [e-mail]

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From [e-mail] (Lee Ann Rucker)
Date: Wed, 30 Nov 1994 11:59:57 +0800
Organization: ParcPlace

In article <3bcbio$[e-mail]>, [e-mail] (Ingemar
Ragnemalm) wrote:

> >(2) Periodically reset the pointer location to
> >the middle of the screen.
>
> This is what I did in HeartQuest. I'm not sure if it's the most portable
> one (though it seems to work on all present Macs - anyone know if it works
> with A/UX?) but it's pretty easy. The drawback is that I have to deped
> on a global that might go away some time.
>
> >There doesn't seem to be any official way of
> >doing either of these.

There is an official way, if the machine has the CursorDevice Manager.
This comes from my PowerMac specific code - I haven't written the Gestalt
check yet, I still use low mem globals for 68k.

                /* Check Gestalt here for 68k (all PowerMacs have it) */
                if (!gCrsrDevice) do {
                        CrsrDevNextDevice(&gCrsrDevice);
                } while (gCrsrDevice && (gCrsrDevice->devClass != kDeviceClassMouse));


...


        if (gCrsrDevice) {
                CrsrDevMoveTo(gCrsrDevice, newPT.h, newPT.v);
 }
 else {
        /* set using low memory globals */
 }

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

>From [e-mail] (Richard Bleasdale)
Date: Tue, 6 Dec 1994 04:02:57 GMT
Organization: Demon Internet

In article <3bb7f5$[e-mail]>, [e-mail]
(Greg Ewing) wrote:

>
> Various games, such as Oxyd and Wolf 3D, use the
> mouse as a relative rather than absolute motion
> device. That is, moving the mouse causes some
> corresponding motion in the game, but there is
> no limit of the mouse hitting the edge of the
> screen.
>
> How is this accomplished? Two approaches I
> can think of are:
>
> (1) Somehow intercept the motion signals coming
> from the mouse at a lower level than the usual
> event mechanism.
>
> (2) Periodically reset the pointer location to
> the middle of the screen.
>
> There doesn't seem to be any official way of
> doing either of these. Does anyone know how
> the trick is usually done, and what is the
> least non-portable way of going about it?
>
> Greg Ewing, Computer Science Dept, +--------------------------------------+
> University of Canterbury,        | A citizen of NewZealandCorp, a       |
> Christchurch, New Zealand        | wholly-owned subsidiary of Japan Inc.|
> [e-mail]       +--------------------------------------+

// I use this stuff in my code...
//I cant remember how it works...But it still works on PowerPC
void    StillMouseIncrement(Point*,Point*);
void    StillMouseIncrement(Here,Inc)
Point   *Here,*Inc;
{/* see MacTutor July 1989 p 88 'Cursor Control' by Robert Gibson*/
Point   *MTemp=(Point*)0x828,*RawMouse=(Point*)0x82c,*Mouse=(Point*)0x830;
short   *CrsrNew=(short*)0x8ce;
*Inc=*MTemp;
Inc->v-=Here->v;
Inc->h-=Here->h;
*MTemp=*Here;
*RawMouse=*Here;
*Mouse=*Here;
*CrsrNew=-1;
}

Richard Bleasdale
[e-mail]

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

>From [e-mail] (Harold Ekstrom)
Subject: How to convert a Picture to a PixPat?
Date: Wed, 30 Nov 1994 18:54:28 -0800
Organization: Ag Group


I'm trying to convert a pict (from the clipboard copied from the
System 7.5 Desktop Patterns control panel) to a PixPat.
Any help?

Thanks,
harold
- ------------------------------------------------------------
Harold Ekstrom
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp


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

>From [e-mail] (Bryan Horling)
Date: Sat, 03 Dec 1994 11:49:46 -0500
Organization: Trinity College

In article <[e-mail]>,
[e-mail] (Harold Ekstrom) wrote:

> I'm trying to convert a pict (from the clipboard copied from the
> System 7.5 Desktop Patterns control panel) to a PixPat.
> Any help?

You should just be able to paste it into a ppat resource (assumming it's <
64x64).  I think the Desktop Patterns are already in ppat resources in the
first place, so if you opened it up with ResEdit you could cut & paste
them directly into your program.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
       --Bryan Horling--       |  >>[e-mail]<<
       -Head Consultant-       |     Trinity College, #701235
  "Do not use GAK on varnished |     300 Summit St
    on unvarnished surfaces"   |     Hartford, CT 06106-3100
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                http://shakti.trincoll.edu/~bhorling

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

>From Jens Alfke <[e-mail]>
Date: Tue, 6 Dec 1994 17:40:16 GMT
Organization: Apple Computer

Harold Ekstrom, [e-mail] writes:
> I'm trying to convert a pict (from the clipboard copied from the
> System 7.5 Desktop Patterns control panel) to a PixPat.
> Any help?

You need to draw the picture into an offscreen GWorld of the proper
dimensions, and then stuff the GWorld's PixMap into the PixPat. The hard part
of this is figuring out the proper color table to use for the PixMap -- I had
to write this stuff by hand for Wallpaper, but fortunately 7.0 and later
include the Picture Utilities that will do things like generate a good color
table for a PICT.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

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

>From [e-mail] (Mark Rogers)
Subject: Info on BlockMoveData ?
Date: Tue, 29 Nov 1994 15:27:25 GMT
Organization: Office Workstations Ltd.

Does anyone know where I can get some information on the BlockMoveData
trap. Specifically I want to know when it's safe to call and which
systems it's available on.

The only reference I can find is in Tech Note OS 05 "System Update 3.0"
but I seem to recall seeing a more complete discussion sometime in the
last 12 months.

Thanks,

    Mark Rogers (all opinions are my own)
    Office Workstations Ltd.
    Edinburgh, UK
    [e-mail]


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

>From [e-mail] (Ken Prehoda)
Date: Tue, 29 Nov 1994 14:45:10 -0600
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <[e-mail]>, [e-mail] (Mark Rogers) wrote:

> Does anyone know where I can get some information on the BlockMoveData
> trap. Specifically I want to know when it's safe to call and which
> systems it's available on.
>
> The only reference I can find is in Tech Note OS 05 "System Update 3.0"
> but I seem to recall seeing a more complete discussion sometime in the
> last 12 months.

It's always safe to call.  If it isn't present, then the regular,
instruction cache flushing BlockMove is called.

I believe the only reference to BlockMoveData _is_ the tech note that you cite.

Ken Prehoda
Department of Biochemistry
University of Wisconsin-Madison
[e-mail]

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

>From [e-mail] (Christopher Larson)
Date: 29 Nov 1994 22:45:38 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] (Mark Rogers) writes:
>Does anyone know where I can get some information on the BlockMoveData
>trap. Specifically I want to know when it's safe to call and which
>systems it's available on.
>
>The only reference I can find is in Tech Note OS 05 "System Update 3.0"
>but I seem to recall seeing a more complete discussion sometime in the
>last 12 months.

BlockMoveData() is just BlockMove() with one of the trap selector bits
(or whatever those bits are called -- the same ones you use for SYS and
CLEAR Memory Manager calls) set. This bit tells the OS that code was not
moved so the instruction cache need not be flushed.

BlockMoveData() is just as safe as BlockMove(); you can use it at interrupt
time, etc. Because BlockMoveData() uses the same trap as BlockMove(), it can
be used on _any_ system. BlockMoveData() is implemented by extending the
existing BlockMove() routine to examine this slector bit and change its
cache flushing behavior acordingly. Thus, if BlockMoveData() is not
implemented, a normal BlockMove() will occur, including the cache flush
if the block was 12 (I think) bytes or longer.

BlockMoveData() is implemented in System Update 3.0 (as I'm sure you
know) and System 7.5 (I think).

The only place I know that any of this is documented is the Tech Note you
mention above. There was some discussion here (well, in csmp anyway) a
while ago but I don't recall any official source of information entering
the discussion.

Sorry about all the "I think"s, I'm away from my Mac at the moment.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
Death to the Trojans! Go Bruins!

(Insert disclaimer here)
Internet: [e-mail]

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

>From [e-mail] (John W. Baxter)
Date: Tue, 29 Nov 1994 14:05:42 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Mark Rogers) wrote:

> Does anyone know where I can get some information on the BlockMoveData
> trap. Specifically I want to know when it's safe to call and which
> systems it's available on.

BlockMoveData is safe to call anytime BlockMove is, unless what you are
moving is object code.  BlockMoveData's job is to not flush the
instruction cache on 68040 machines.  The trap differs from the BlockMove
trap in only one bit...ROMs which don't know about BlockMoveData don't
notice the bit, and execute BlockMove.
>
--John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

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

>From [e-mail] (Fred Toth)
Subject: Installer advice please?
Date: 2 Dec 1994 02:19:10 GMT
Organization: Cybernetx, Inc.

Hi folks. We needed a slick installation package for our application
some time ago. We looked briefly at the Apple installer stuff, but
quickly settled on Stuffit Installer Maker from Aladdin (Great product!).

Now, of course, things have gotten more complicated, and we're
looking for solutions again. We need to do some things that Installer
Maker won't do.

Could anyone advise on these issues:

1. We know we can add functionality to Installer Maker by linking in
C modules. How does this compare with off-the-shelf functionality
available from Apple's installer?

2. Putting together installation packages in Installer Maker is a snap.
I've heard that creating Apple installer scripts is painful. Any comments?

3. Are there other products out there that we should consider?

Many thanks,

Fred Toth, [e-mail]

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

>From [e-mail] (BSUTTER)
Date: 7 Dec 1994 00:30:14 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <3bm06u$[e-mail]>, [e-mail] (Fred
Toth) writes:

Hi!
I work for MindVision software in Lincoln, NE
[phone]
We have an installer application similar to InstallerMaker with MANY
additional features.
You can set up to 96 different packages.
You can call external codes before and after every file that gets
installed, so you can modify the file after it's installed, or whatever.
You can get a full working version of the installer to try it out by
calling Mindvision at the above phone number. All it does is bring up a
slash screen saying it is an unauthorized copy, or something like that.

It's called Developer VISE. Several major companies are using it including
Intuit, Adobe, Apple (for internal software), Symantec, ...

Hope this helps,

Brian Sutter


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

>From [e-mail] (Johanna Andrews)
Date: Fri, 09 Dec 1994 17:28:15 -0700
Organization: Apple Computer

In article <3bm06u$[e-mail]>, [e-mail] (Fred
Toth) wrote:

> Hi folks. We needed a slick installation package for our application
> some time ago. We looked briefly at the Apple installer stuff, but
> quickly settled on Stuffit Installer Maker from Aladdin (Great product!).
>
> Now, of course, things have gotten more complicated, and we're
> looking for solutions again. We need to do some things that Installer
> Maker won't do.
>
> Could anyone advise on these issues:
>
> 1. We know we can add functionality to Installer Maker by linking in
> C modules. How does this compare with off-the-shelf functionality
> available from Apple's installer?
>
> 2. Putting together installation packages in Installer Maker is a snap.
> I've heard that creating Apple installer scripts is painful. Any comments?
>
> 3. Are there other products out there that we should consider?
>
> Many thanks,
>
> Fred Toth, [e-mail]

Hi Fred,

Regarding Issue #1 - I've linked C modules into Apple installers, but
not Aladdin installers.  However, based on looking over Aladdin's
documentation,
I'd say Aladdin's functionality is roughly comparable with respect to this
feature.

Regarding issue #2 - The first time you create an Apple Installer it's
painful (fairly steep learning curve), but once you've written one
installer script it's not too bad.  One advantage the Aladdin installer
offers is that compression is automatic while the Apple installer requires
that files be compressed separately if compression is desired, using a
separate compression tool (such as InstaCompOne, which I believe is
included in the Installer 4.0.3 SDK).  Also, Aladdin Installers I have
created have been smaller and faster than analagous Apple Installers when
compression was necessary.

It used to be that InstallerMaker had significantly fewer features than
Apple's installer and was less flexible, but in the 2.0 version, Aladdin is
catching up.  However, Apple's custom install interface is still much more
configurable than Aladdin's.  Also, you can create updaters with the Apple
Installer (merging resources into existing files is supported) but not with
InstallerMaker.

I can't address issue #3, since I haven't checked out any other products.

In general, I would recommend that you figure out exactly what your
installer
needs to do and then find the package that offers the features you require
for the best price.

Good Luck,

Johanna Andrews
[e-mail]

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

>From [e-mail] (Jon W{tte)
Subject: Mac FAQ now available as HTML using WWW!
Date: Mon, 05 Dec 1994 22:32:08 +0100
Organization: The Conspiracy

There are some issues about the FAQ:

1) Someone keeps posting old and outdated versions of the FAQ
questions in the info group. The real FAQ is only posted in
comp.sys.mac.programmer, comp.answers and news.answers, and
available for ftp on rtfm.mit.edu and nada.kth.se.

2) The FAQ is now available as HTML document, either using
ftp://ftp.nada.kth.se/pub/hacks/mac-faq/mac-faq.html OR from my
home page http://www.nada.kth.se/~d88-jwa.

The HTML version is parsed from the "real" version using a
simple parser I wrote, so there may be strangenesses or
inelegancies. Please report them to me.

3) The new co-maintainer and butler of the FAQ is Chris;
[e-mail]. Mail your bug reports, requests etc to
him; he collects it all and sends me a new, updated FAQ once a
month.

Cheers,

                                / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
   Had I known that I would program Macintosh for a living
   maybe I would have turned away from computers altogether.
                                            -- Hao-yang Wang


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

>From [e-mail] (Zviki Cohen)
Subject: PowerPlant vs. MacApp - opinions ?
Date: Wed, 9 Nov 1994 08:42:38 GMT
Organization: TECHNION - Izrael Institute of Technology

        Hello !

        Well, the title says most of it - I'm about to start a project using
CodeWarrior and I can choose to use either PowerPlant or MacApp. Which one is
better ?  Are there any major diffrences that anyone can point out ?

                TIA,
                                Zviki Cohen



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

>From [e-mail] (John W. Baxter)
Date: Wed, 09 Nov 1994 10:25:02 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Zviki Cohen) wrote:

>         Hello !
>
>         Well, the title says most of it - I'm about to start a project using
> CodeWarrior and I can choose to use either PowerPlant or MacApp. Which one is
> better ?  Are there any major diffrences that anyone can point out ?

MacApp:   Solid, stolid old code (more than 10 years old in concept...it
was being worked on before first Mac release).  At the same time, it's
based on oldish design ideas, and it has fallen behind the new additions
to the Mac Op Sys (can't say "Mac OS" any more without a license).
[Version 3.5 will somewhat catch up.]  Essentially based on a tree
structure of classes (although your own code need not be part of the
tree...you can use your own classes not based on TObject if you like, and
it's often best for the "engine" part of your code).  Can build for System
6 (if that matters to you).

PowerPlant:  Fresh and new, still evolving.  Based on a forest structure,
and the dependencies between classes are reduced as much as possible.
[You can pick up the menu handling and use just that in your own app, just
as an example...no easy way to do that with MacApp.]  PP apps are
scriptable and recordable unless you go out of  your way to break that.
Apps require System 7.

PowerPlant is Greg Dow's second chance to do this (TCL having been the
first), and he's taking good advantage of the more modern tools at his
disposal.

Bottom line:  it depends.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

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

>From red.riders
Date: Thu, 10 Nov 1994 00:53:57 -0500
Organization: DSC/Voicenet - BBS/Unix Shells/SLIP/NEWS - [phone]

In article <[e-mail]>,
[e-mail] (John W. Baxter) wrote:

>
> Bottom line:  it depends.
>

Yeah, on when you actually want to ship your app.

This is not a knock on PP. It simply is not yet
ready to do big time apps. Yet. MacApp today is
by FAR the best Mac framework solution available. Con-
trary to popular belief, it really isn't even a
close race, unless you're making an app that has
relatively limited scope (like some sort of utility).

I would use anything that was better. I have no
hidden agendas against TCL or PP. Both have their
good points. I used TCL before MacApp in order to
avoid having to climb MacApp's (overstated) learning
curve. And I seriously examined PP and it's "modern"
approach to application design. Shows good promise, but it
simply is not yet something I would rely upon, or stake
my reputation upon when delivering a product.

Forget the "forest" and "monolithic" garbage. It doesn't
matter in a big app, particularly when the monolith is
a giant body of code that you never have to change.

Apple wants you to write OpenDoc parts; so they are telling
you that monolithic OOP frameworks are dinosaurs. Keep in
mind that Apple also told you that 040's were dinosaurs
the day PPC machines shipped. Still selling plenty 040 boxes
though.

Don't believe their hogwash, unless you plan on
writing something today that 0.0% of Mac users are currently
waiting for (OpenDoc parts). If you can wait 3 years to get
paid, then write OD parts. If you want to ship an app in 3-6
months, then MacApp is like having a ticket on the Concorde.

You will not believe how fast a MacApp application comes together.

Schedules are measured in days, not months. You can struggle with
PP today, and be an expert. OR you could ship product NOW, and
learn PP when it's API stops changing, and is stable enough to
take seriously.

MacApp is remarkably detailed, solid, and capable.
PP is really years away from this level of polish, and those
who are using it today are hampered by the amount of
stuff they have to write (and debug!) that MacApp users
have taken for granted for years. Tons and tons of services
are in MacApp, that PP may never have.

PP is catching up to MacApp faster than MacApp is pulling
away. Soon the choice will be a tough one. But not today.
The best thing to do is learn a bit about PP, and it's
ways and methodologies. Plan on possibly migrating to PP in the
future. Maybe you won't ever do it, but good OOP design will
allow your classes to function under EITHER framework; IF you
plan, design, and code your stuff with this mindset.

SOLID knowledge and use of C++ will help you a lot. Worth the effort.
Whatever you do though, USE CODEWARRIOR!!!!

the red riders!

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

>From [e-mail] (DKEvery)
Date: 10 Nov 1994 13:20:07 -0500
Organization: America Online, Inc. (1-800-827-6364)

Also...

MacApp abstracts you MORE from the toolbox (not completely, but
more-so).... and has more layers, and is a more full featured FrameWork
(not better, just more abstracted and more to learn).

For the most part if you are learning a framework and come from Mac
Programming... the PowerPlant will be much easier and better.... if you
are coming from heavy OOP and don't understand Mac programming (and have
to learn everything anyways)... then MacApp is probably better.

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

>From [e-mail] (Anthony Berno)
Date: Thu, 10 Nov 1994 13:31:34 -0800
Organization: Stanford DNA Sequence and Technology Center

In article
<[e-mail]>,
red.riders wrote:

> In article <[e-mail]>,
> [e-mail] (John W. Baxter) wrote:
>
> > Bottom line:  it depends.
>
> Yeah, on when you actually want to ship your app.

Unfortunately, this is true. PP, although it is a nice start, is a very
thin and cantankerous framework. Although it is much better than TCL
(which is, imho, a creeping horror that deserves to die) I would have been
much better off with MacApp in my current project, and I wish I had
started with that instead of PP.

The main problem is that the classes are not abstract enough - you still
have to dig around in the internals. For example, in using a popup menu, I
actually have to fiddle with the menu handle! That sucks! And, I've been
trying for half an hour to get my popup to show a particular item when it
is first created, and I can't manage it. Aargh!

Also, the classes are not very robust. For example, if you forget to call
UDesktop::Deactivate and UDesktop::Activate before and after a call that
generates a modal dialog, your desktop will be permanently screwed, and
won't figure out by itself that something is wrong.

I haven't actually *written* anything with MacApp, but unless PP gets a
lot better, I'm not going to use it for my next project. Even though
MacApp doesn't seem to support AEOM, it looks like the better choice.

(Actually, I'd rather be using Dylan. ;-)

> SOLID knowledge and use of C++ will help you a lot. Worth the effort.
> Whatever you do though, USE CODEWARRIOR!!!!

Hear hear. Excellent advice.

-Anthony

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

>From [e-mail] (Brian Stern)
Date: 11 Nov 1994 04:12:11 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Anthony Berno) wrote:

< The main problem is that the classes are not abstract enough - you still
< have to dig around in the internals. For example, in using a popup menu, I
< actually have to fiddle with the menu handle! That sucks! And, I've been
< trying for half an hour to get my popup to show a particular item when it
< is first created, and I can't manage it. Aargh!
<
Try this:

thePopUp->SetValue( 5 );//Sets the popup to the 5th item in the menu

Although I will say that LListBox has no methods for adding rows
or columns.

< Also, the classes are not very robust. For example, if you forget to call
< UDesktop::Deactivate and UDesktop::Activate before and after a call that
< generates a modal dialog, your desktop will be permanently screwed, and
< won't figure out by itself that something is wrong.
<

This is mentioned in the docs and one of the sample apps.

<
< -Anthony

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

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

>From [e-mail] (Eric Scouten)
Date: Fri, 11 Nov 1994 10:08:28 -0600
Organization: University of Illinois

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> In article <[e-mail]>,
> [e-mail] (Anthony Berno) wrote:
>
> < The main problem is that the classes are not abstract enough - you still
> < have to dig around in the internals. For example, in using a popup menu, I
> < actually have to fiddle with the menu handle! That sucks!

Really. I actually rather like it. It's part of what makes PowerPlant a
nice, lightweight class library.

-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

IMPORTANT NOTICE TO READERS: The entire physical universe, including this
message, may one day collapse back into an infinitesimally small space.
Should another universe subsequently re-emerge, the existence of this message
cannot be guaranteed.
   -with apologies to Devine & Cohen (Absolute Zero Gravity)

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

>From [e-mail] (Sak Wathanasin)
Date: Sat, 12 Nov 94 21:24:37 GMT
Organization: Network Analysis Ltd


In article <[e-mail]>
(comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer),
[e-mail] (McCammond) writes:

> If the design ideas in
> PowerPlant had been incorporated into the application I'm working on (a
> 500,000 line MacApp application--yes 500,000 lines) when it was
> created, then I would have a lot fewer headaches.

So are you converting that 500K line appl to PP? If so, how did you fare? If
not, why not?

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

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

>From [e-mail] (Anthony Berno)
Date: Mon, 14 Nov 1994 09:45:14 -0800
Organization: Stanford DNA Sequence and Technology Center


In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> Try this:
>
> thePopUp->SetValue( 5 );//Sets the popup to the 5th item in the menu

...Except, of course, this didn't work. The reason it didn't work cuts to
the core of what I've been trying to say about the design of PowerPlant.

Because I had a popup whose contents were not determined until runtime, I
had to add items to the popup. Because there is no method for doing this,
I had to add it to the Mac menu directly, using GetMacMenuH() to retrieve
it.

The menu started out with zero items, so of course the value in mMaxValue
was zero. When adding values to the menu handle, I forgot to also update
the value in mMaxValue, thus causing the object to be in an internally
inconsistent state.

When I tried to use SetValue(), it said, "Oh, that is greater than the
maximum value of zero, so I will set the popup menu's value to zero
without telling the programmer about it."

This is an easy mistake to make, and it came about ***because the
encapsulation of the class was broken by forcing me to access the menu
handle***.

The exposure of the MenuHandle goes against the most basic principles of
object-oriented design. The WHOLE POINT of having objects is so that you
can do things without having to worry about maintaining their internal
state. This is much more important than polymorphism, multiple
inheritance, or any other object-oriented feature. While I respect a lot
of things that Greg Dow has done, and I really like a lot of things about
PowerPlant, things like this waste an enormous amount of time and money.

> Although I will say that LListBox has no methods for adding rows
> or columns.

Indeed. This results in the same problems I describe above. LListBox has
such simple behavior, I think it would be easier to implement it without
the ListManager.

> < Also, the classes are not very robust. For example, if you forget to call
> < UDesktop::Deactivate and UDesktop::Activate before and after a call that
> < generates a modal dialog, your desktop will be permanently screwed, and
> < won't figure out by itself that something is wrong.
> <
>
> This is mentioned in the docs and one of the sample apps.

Documentation is not design, and does not substitute for it.There should
be consistency checks in UDesktop to catch these things. A major
difference between a good and bad framework is how often you have to run
back to the documentation - a good framework does what you expect, with no
surprises.

-Anthony

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

>From [e-mail] (Anthony Berno)
Date: Mon, 14 Nov 1994 10:54:41 -0800
Organization: Stanford DNA Sequence and Technology Center

In article <[e-mail]>,
[e-mail] (McCammond) wrote:

> What the heck, I'll play devil's advocateI
>
> (step up on the soap box)

[lots about PP deleted]

Yes, to be fair, I have to agree with your points about the design of
PowerPlant. The intelligent use of multiple inheritance is an enormous
advantage.

After all the negativity I've generated, I want to second the notion that
PP does have a lot going for its future, despite what I consider to be
some serious problems at present. I hope (dearly!) that PP evolves into
the robust, elegant framework that it deserves to be.

-Anthony

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

>From [e-mail] (Ron Davis)
Date: Mon, 14 Nov 1994 15:40:00 -0400
Organization: Creative Cybernetics -online services (704-549-5553 voice)

I'm going to jump in on this because I'm taking a break from cursing MPW
and MacApp.  I just recieved a rather small MacApp app (if there is such a
thing) that I have to make some modifications to.  It is driving me up the
wall.  I guess I'm spoiled I've been using PP for the last three or four
months and it is so much easier.

MacApp is too big and complicated.  You have to have a special tool just
to compile something in it.  PP is lean.

You have to have an idea what all of MacApp is doing from the beginning.
In PP you only have to learn the parts you are using.

MacApp has its own special way of handling memory and segments.  PP
doesn't screw around with the basic structure of a Mac program.  This
memory thing is why it is so hard to get MacApp to work under
CodeWarrior.  I understand the people from Symantec got PP running under
thier system in a matter of hours, where as they never got MacApp to work
with Think.

And finally, didn't Apple announce they  weren't going to support MacApp
anymore?  Or was this a post-Bedrock promise that has been recended?

Ahhh...I feel better letting a little of that steam.

___________________________________________________________________________
"I want to know God's thoughts...the rest are details."
                                           -- Albert Einstein
_________________________________________
Ron Davis                                  [e-mail]        Datawatch, Research Triangle Park, NC      [phone]
            **** Opinions are MINE, not Datawatch's. ****
        **** They don't pay me enough to own my opinions ****

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

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 01:29:42 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
|>
|> ...Except, of course, this didn't work. The reason it didn't work cuts to
|> the core of what I've been trying to say about the design of PowerPlant.

What you're complaining about doesn't seem to me to be
a fundamental flaw in the design of PowerPlant. It's
just a reflection of the fact that the class you're
using wasn't designed to do what you want.

Whenever you want to extend a class to do something
its author hadn't anticipated, you have to be prepared
to understand some of its internals.

|> This is an easy mistake to make, and it came about ***because the
|> encapsulation of the class was broken by forcing me to access the menu
|> handle***.

Make yourself a subclass, and add a method which adds a
menu item and does whatever is necessary to keep the
internal state consistent. Now you have a new, properly
encapsulated class which does what you want. Put it
away for future use. If you're feeling generous enough,
post it to the net.

PowerPlant certainly does not yet do everything
everyone might want it to do. But you've given no
reason why the basic structure is not sufficient to
build upon.

|> LListBox has
|> such simple behavior, I think it would be easier to implement it without
|> the ListManager.

I can believe that. Recently I added a list view class to a
framework of my own I've been developing in Object Pascal.
I didn't even consider using the List Manager - it would
have taken more contortions just to interface it to my
object-oriented code than it took to do it all from
scratch.

In today's environment of OO frameworks, it seems to me
that the List Manager is obsolete. I'd also almost say the
same thing about the Window and Control managers, insofar
as much of what they do could have been done much more
neatly if the whole toolbox had been written in an OO
language from the beginning, which it should have been!

|> -Anthony

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From [e-mail] (Kent Sandvik)
Date: Mon, 14 Nov 1994 22:30:55 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3a92u6$[e-mail]>,
[e-mail] (Greg Ewing) wrote:
> In today's environment of OO frameworks, it seems to me
> that the List Manager is obsolete. I'd also almost say the
> same thing about the Window and Control managers, insofar
> as much of what they do could have been done much more
> neatly if the whole toolbox had been written in an OO
> language from the beginning, which it should have been!

They were, actually -- Lisa Toolbox. And there was a reason these were
rewritten in hand-coded asm in the Mac incarnation. But I agree, CPUs are
now fast enough to handle additional overhead of the toolbox.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (Anthony Berno)
Date: Tue, 15 Nov 1994 09:06:13 -0800
Organization: Stanford DNA Sequence and Technology Center

In article <3a92u6$[e-mail]>,
[e-mail] (Greg Ewing) wrote:

> In article <[e-mail]>,
[e-mail] (Anthony Berno) writes:
> |>
> |> ...Except, of course, this didn't work. The reason it didn't work cuts to
> |> the core of what I've been trying to say about the design of PowerPlant.
>
> What you're complaining about doesn't seem to me to be
> a fundamental flaw in the design of PowerPlant. It's
> just a reflection of the fact that the class you're
> using wasn't designed to do what you want.
>
> Whenever you want to extend a class to do something
> its author hadn't anticipated, you have to be prepared
> to understand some of its internals.

Just a sec here... all I wanted to do was to add an item to a popup menu!
Saying "the class wasn't designed for that" is like saying "This car
wasn't designed to have gas put into the tank" after it explodes at the
gas station.

-Anthony

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

>From [e-mail] (Scott Ellsworth)
Date: 15 Nov 1994 09:24:00 -0800
Organization: KAIWAN Internet (310/527-4279,818/756-0180,714/638-4133)

One minor point - I was always taught to add methods to a class when
modifying base behaviors.  Thus, whenever I need to fiddle with the
underlying mac stuff, I wrap a member function around it and make sure
that I fiddle with PowerPlant internals at the same time/place.

I realize that putting the modified behavior in a class wrapper does not
magically cause it to understand the PP internals, and it would be really
handy if one never needed to modify the internals, but I find that it
works as a good reminder to me that I have to make sure I am not stomping
on any behaviors.

Scott

--
Scott Ellsworth          [e-mail]
Missing mudders, put your email addrs in the directory!
"This is the aorta of the last person to ask me that" - Scott Adams

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

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 22:27:46 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
|> And there was a reason these were
|> rewritten in hand-coded asm in the Mac incarnation.

But they could have written it in OO assembly language...

|> Kent Sandvik   [e-mail]   New Media Analyst/Programmer

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 22:34:18 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
|> Saying "the class wasn't designed for that" is like saying "This car
|> wasn't designed to have gas put into the tank" after it explodes at the
|> gas station.

You seemed to be saying "The author of PopUpMenu forgot to
include a method for adding items, so the basic, underlying
structure of PowerPlant is fundamentally and hopelessly
flawed!"

That's what I was arguing against.

|> -Anthony

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From Darryl Trujillo <[e-mail]>
Date: Tue, 15 Nov 1994 21:55:42 GMT
Organization: Occidental Palace

In article <[e-mail]> Ron Davis,
[e-mail] writes:
>MacApp has its own special way of handling memory and segments.  PP
>doesn't screw around with the basic structure of a Mac program.  This
>memory thing is why it is so hard to get MacApp to work under
>CodeWarrior.  I understand the people from Symantec got PP running under
>thier system in a matter of hours, where as they never got MacApp to work
>with Think.

I think this had more to do with Think's lack of support for #pragma
segment than basic MacApp design.

        - dmt
+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 22:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Greg Ewing) writes:
> In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
> |> Saying "the class wasn't designed for that" is like saying "This car
> |> wasn't designed to have gas put into the tank" after it explodes at the
> |> gas station.
>
> You seemed to be saying "The author of PopUpMenu forgot to
> include a method for adding items, so the basic, underlying
> structure of PowerPlant is fundamentally and hopelessly
> flawed!"
>
> That's what I was arguing against.

If MWerks say "we're planning to add more functionality in CW6" then fine.

But they seem to be saying: "We're not going to add that functionailty.  Not
encapsulating the underlying toolbox capabilities is a design feature, not
an oversight."

If they're going to take that kind of approach (which I disagree with), and
make the programmer reach through and fondle toolbox structures by themselves
anyway, then they shouldn't be caching *any* data (such as the number of items
in the menu) in the PP object.  If it's oversight they are forgiven.  If it's
by design, it's wrong.

-- Bruce

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

>From [e-mail] (Pete Gontier)
Date: Wed, 16 Nov 1994 11:41:33 -0700
Organization: Novell, Inc., Walnut Creek /Macintosh Site

In article <[e-mail]>,
[e-mail] (Anthony Berno) wrote:

> Just a sec here... all I wanted to do was to add an item to a popup menu!
> Saying "the class wasn't designed for that" is like saying "This car
> wasn't designed to have gas put into the tank" after it explodes at the
> gas station.

Nobody said the class wasn't broken. (Nobody said it was, either, but I am
assuming for the sake of discussion that your observations about it are
damning enough that most reasonable observers would consider it broken.)
However, your earlier post seemed to claim that since the popup menu class
is broken, PowerPlant is broken. That's a generalization fallacy. I'm not
exactly what I would call a PowerPlant fan, but bashing its overall design
because of the deficiencies of one class is wrong.

A much more constructive use of your energy would be to alter the popup
menu class to work the way you want it to and send your changes to
Metrowerks, through which they will be routed to Greg. He's a receptive
guy.

If all you want is a popup menu that works the way you want it, then
sub-classing is another option. I'd rather see sub-classing used to add
functionality than to correct deficiencies, though.

--

 Views expressed here do not necessarily reflect those of my employer.

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

>From Mike Lockwood <[e-mail]>
Date: 17 Nov 1994 01:13:27 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>
McCammond, [e-mail] writes:
>As far as forgetting the "monolithic" vs. "forest" argument, RR can't
>so easily dismiss what is a major evolutionary step forward in OO
>design. Contrary to what RR is saying, I would argue that PowerPlant's
>design philosophy will allow it to be used to create applications that
>solve even more complex problems more quickly and easily. It takes the
>best advantages of OO design and builds on them--namely encapsulation
>and separation of concerns. Let's just take one example: TView. In
>MacApp it handles drawing, mouse clicks, keyboard and menu events, idle
>task handling. I could probably think of a few more things thrown into
>TView, if I put my mind to it. Face it. MacApp is bloated.
>
>PowerPlant's design is simply simpler. Easier to grasp. More natural
>and cleaner once you do. Let's take the functionality in TView.
>PowerPlant has an LPane class whose only responsibility is drawing on
>the screen and accepting clicks. LCommander handles keyboard and menu
>events. LPeriodical handles idle tasks. How is this used? Let's take an
>edit text, it is drawn on the screen, so it inherits from LPane. It
>handles keyboard events, so it inherits from LCommander. It
>periodically blinks the insertion point, so it inherits from
>LPeriodical. Each of these classes can be understood and used
>separately--or not used at all if its not appropriate. This leads to
>more cleanly separating functionality as well as having finer grained
>classes with fewer dependencies--a structure which is easier to learn
>and simpler to maintain.

I haven't had a chance to try Power Plant yet, so I can't make any
recommendations about Power Plant vs. MacApp.  But I was wondering...

If you want to have a view that can draw, handle mouse clicks, respond to
menu events and Apple events, do things at idle time (blink the cursor or
animate a selection with marching ants), etc.  it sounds like you have to
subclass from LPane, LCommander, LPeriodical and possibly some other
classes.  How well has this been working out for people?  I haven't used
MI in C++, but have heard that C++ MI has a lot of gotchas that you have
to be aware of.  Is this ever a problem, or am I nervous about this for
no good reason?

I thought about doing something like this in the Dylan framework, but
decided to do make the view system more like MacApp's view system.  I
wanted all views to have the ability to handle events, so you can add
behaviors to any view.  Providing the ability to add a behavior to any
view is critical for supporting an interface builder that can do live
editing of views in your running program.  I'm not sure how this could be
implemented in a view system that has views with no event handling
capabilities, but I suppose you could find a way to do it.
- ---------------------------------------------------------------------
Mike Lockwood                              [e-mail]
Full Time Dylan Hacker/Part Time CodeWarrior Hacker
Apple Computer, Inc.       "still cannot fix this broken machine" - NIN

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

>From [e-mail] (Eric Scouten)
Date: Thu, 17 Nov 1994 19:38:20 -0600
Organization: University of Illinois

In article <3aeann$[e-mail]>, Mike Lockwood
<[e-mail]> wrote:

> If you want to have a view that can draw, handle mouse clicks, respond to
> menu events and Apple events, do things at idle time (blink the cursor or
> animate a selection with marching ants), etc.  it sounds like you have to
> subclass from LPane, LCommander, LPeriodical and possibly some other
> classes.

Exactly.

> How well has this been working out for people?

Quite well in my mind.


> I haven't used
> MI in C++, but have heard that C++ MI has a lot of gotchas that you have
> to be aware of.  Is this ever a problem, or am I nervous about this for
> no good reason?

I think that the main problem with MI in C++ is that it's intimidating to
the new C++ programmer. (And I'm not intending to insult anybody with that
statement.) It is difficult to explain to somebody that a particular
object is both a LPane, LPeriodical, and an LEditField (or whatever).

But once you wrap your mind around it, it's a very flexible and powerful
mechanism. Here's one reason I like it. In one (hypothetical) application
I'm designing, I may need to display static information, but not respond
to any mouse down events in the window's content areas. Then I can totally
dismiss the LCommander hierarchy from the drawing routines; this makes
them simpler and smaller.

In the next application, I may need all kinds of controls and editable
fields and whatnot. Then I can drag in those methods (which are neatly
grouped in the LCommander base class).

So what I'm saying, in a long-winded way, is that I see no reason to shy
away from multiple inheritance.

-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

This message printed on 100% recycled electrons.

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

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 22:34:18 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
|> Saying "the class wasn't designed for that" is like saying "This car
|> wasn't designed to have gas put into the tank" after it explodes at the
|> gas station.

You seemed to be saying "The author of PopUpMenu forgot to
include a method for adding items, so the basic, underlying
structure of PowerPlant is fundamentally and hopelessly
flawed!"

That's what I was arguing against.

|> -Anthony

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From Darryl Trujillo <[e-mail]>
Date: Tue, 15 Nov 1994 21:55:42 GMT
Organization: Occidental Palace

In article <[e-mail]> Ron Davis,
[e-mail] writes:
>MacApp has its own special way of handling memory and segments.  PP
>doesn't screw around with the basic structure of a Mac program.  This
>memory thing is why it is so hard to get MacApp to work under
>CodeWarrior.  I understand the people from Symantec got PP running under
>thier system in a matter of hours, where as they never got MacApp to work
>with Think.

I think this had more to do with Think's lack of support for #pragma
segment than basic MacApp design.

        - dmt

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

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 22:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Greg Ewing) writes:
> In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
> |> Saying "the class wasn't designed for that" is like saying "This car
> |> wasn't designed to have gas put into the tank" after it explodes at the
> |> gas station.
>
> You seemed to be saying "The author of PopUpMenu forgot to
> include a method for adding items, so the basic, underlying
> structure of PowerPlant is fundamentally and hopelessly
> flawed!"
>
> That's what I was arguing against.

If MWerks say "we're planning to add more functionality in CW6" then fine.

But they seem to be saying: "We're not going to add that functionailty.  Not
encapsulating the underlying toolbox capabilities is a design feature, not
an oversight."

If they're going to take that kind of approach (which I disagree with), and
make the programmer reach through and fondle toolbox structures by themselves
anyway, then they shouldn't be caching *any* data (such as the number of items
in the menu) in the PP object.  If it's oversight they are forgiven.  If it's
by design, it's wrong.

-- Bruce

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

>From [e-mail] (Greg Ewing)
Date: 15 Nov 1994 22:34:18 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
|> Saying "the class wasn't designed for that" is like saying "This car
|> wasn't designed to have gas put into the tank" after it explodes at the
|> gas station.

You seemed to be saying "The author of PopUpMenu forgot to
include a method for adding items, so the basic, underlying
structure of PowerPlant is fundamentally and hopelessly
flawed!"

That's what I was arguing against.

|> -Anthony

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From Darryl Trujillo <[e-mail]>
Date: Tue, 15 Nov 1994 21:55:42 GMT
Organization: Occidental Palace

In article <[e-mail]> Ron Davis,
[e-mail] writes:
>MacApp has its own special way of handling memory and segments.  PP
>doesn't screw around with the basic structure of a Mac program.  This
>memory thing is why it is so hard to get MacApp to work under
>CodeWarrior.  I understand the people from Symantec got PP running under
>thier system in a matter of hours, where as they never got MacApp to work
>with Think.

I think this had more to do with Think's lack of support for #pragma
segment than basic MacApp design.

        - dmt

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

>From [e-mail] (Bruce Hoult)
Date: Wed, 16 Nov 1994 22:55:24 +1300 (NZDT)
Organization: (none)

[e-mail] (Greg Ewing) writes:
> In article <[e-mail]>, [e-mail] (Anthony Berno) writes:
> |> Saying "the class wasn't designed for that" is like saying "This car
> |> wasn't designed to have gas put into the tank" after it explodes at the
> |> gas station.
>
> You seemed to be saying "The author of PopUpMenu forgot to
> include a method for adding items, so the basic, underlying
> structure of PowerPlant is fundamentally and hopelessly
> flawed!"
>
> That's what I was arguing against.

If MWerks say "we're planning to add more functionality in CW6" then fine.

But they seem to be saying: "We're not going to add that functionailty.  Not
encapsulating the underlying toolbox capabilities is a design feature, not
an oversight."

If they're going to take that kind of approach (which I disagree with), and
make the programmer reach through and fondle toolbox structures by themselves
anyway, then they shouldn't be caching *any* data (such as the number of items
in the menu) in the PP object.  If it's oversight they are forgiven.  If it's
by design, it's wrong.

-- Bruce

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

>From [e-mail] (Pete Gontier)
Date: Wed, 16 Nov 1994 11:41:33 -0700
Organization: Novell, Inc., Walnut Creek /Macintosh Site

In article <[e-mail]>,
[e-mail] (Anthony Berno) wrote:

> Just a sec here... all I wanted to do was to add an item to a popup menu!
> Saying "the class wasn't designed for that" is like saying "This car
> wasn't designed to have gas put into the tank" after it explodes at the
> gas station.

Nobody said the class wasn't broken. (Nobody said it was, either, but I am
assuming for the sake of discussion that your observations about it are
damning enough that most reasonable observers would consider it broken.)
However, your earlier post seemed to claim that since the popup menu class
is broken, PowerPlant is broken. That's a generalization fallacy. I'm not
exactly what I would call a PowerPlant fan, but bashing its overall design
because of the deficiencies of one class is wrong.

A much more constructive use of your energy would be to alter the popup
menu class to work the way you want it to and send your changes to
Metrowerks, through which they will be routed to Greg. He's a receptive
guy.

If all you want is a popup menu that works the way you want it, then
sub-classing is another option. I'd rather see sub-classing used to add
functionality than to correct deficiencies, though.

--

 Views expressed here do not necessarily reflect those of my employer.

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

>From Mike Lockwood <[e-mail]>
Date: 17 Nov 1994 01:13:27 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>
McCammond, [e-mail] writes:
>As far as forgetting the "monolithic" vs. "forest" argument, RR can't
>so easily dismiss what is a major evolutionary step forward in OO
>design. Contrary to what RR is saying, I would argue that PowerPlant's
>design philosophy will allow it to be used to create applications that
>solve even more complex problems more quickly and easily. It takes the
>best advantages of OO design and builds on them--namely encapsulation
>and separation of concerns. Let's just take one example: TView. In
>MacApp it handles drawing, mouse clicks, keyboard and menu events, idle
>task handling. I could probably think of a few more things thrown into
>TView, if I put my mind to it. Face it. MacApp is bloated.
>
>PowerPlant's design is simply simpler. Easier to grasp. More natural
>and cleaner once you do. Let's take the functionality in TView.
>PowerPlant has an LPane class whose only responsibility is drawing on
>the screen and accepting clicks. LCommander handles keyboard and menu
>events. LPeriodical handles idle tasks. How is this used? Let's take an
>edit text, it is drawn on the screen, so it inherits from LPane. It
>handles keyboard events, so it inherits from LCommander. It
>periodically blinks the insertion point, so it inherits from
>LPeriodical. Each of these classes can be understood and used
>separately--or not used at all if its not appropriate. This leads to
>more cleanly separating functionality as well as having finer grained
>classes with fewer dependencies--a structure which is easier to learn
>and simpler to maintain.

I haven't had a chance to try Power Plant yet, so I can't make any
recommendations about Power Plant vs. MacApp.  But I was wondering...

If you want to have a view that can draw, handle mouse clicks, respond to
menu events and Apple events, do things at idle time (blink the cursor or
animate a selection with marching ants), etc.  it sounds like you have to
subclass from LPane, LCommander, LPeriodical and possibly some other
classes.  How well has this been working out for people?  I haven't used
MI in C++, but have heard that C++ MI has a lot of gotchas that you have
to be aware of.  Is this ever a problem, or am I nervous about this for
no good reason?

I thought about doing something like this in the Dylan framework, but
decided to do make the view system more like MacApp's view system.  I
wanted all views to have the ability to handle events, so you can add
behaviors to any view.  Providing the ability to add a behavior to any
view is critical for supporting an interface builder that can do live
editing of views in your running program.  I'm not sure how this could be
implemented in a view system that has views with no event handling
capabilities, but I suppose you could find a way to do it.
- ---------------------------------------------------------------------
Mike Lockwood                              [e-mail]
Full Time Dylan Hacker/Part Time CodeWarrior Hacker
Apple Computer, Inc.       "still cannot fix this broken machine" - NIN

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

>From [e-mail] (Eric Scouten)
Date: Thu, 17 Nov 1994 19:38:20 -0600
Organization: University of Illinois

In article <3aeann$[e-mail]>, Mike Lockwood
<[e-mail]> wrote:

> If you want to have a view that can draw, handle mouse clicks, respond to
> menu events and Apple events, do things at idle time (blink the cursor or
> animate a selection with marching ants), etc.  it sounds like you have to
> subclass from LPane, LCommander, LPeriodical and possibly some other
> classes.

Exactly.

> How well has this been working out for people?

Quite well in my mind.


> I haven't used
> MI in C++, but have heard that C++ MI has a lot of gotchas that you have
> to be aware of.  Is this ever a problem, or am I nervous about this for
> no good reason?

I think that the main problem with MI in C++ is that it's intimidating to
the new C++ programmer. (And I'm not intending to insult anybody with that
statement.) It is difficult to explain to somebody that a particular
object is both a LPane, LPeriodical, and an LEditField (or whatever).

But once you wrap your mind around it, it's a very flexible and powerful
mechanism. Here's one reason I like it. In one (hypothetical) application
I'm designing, I may need to display static information, but not respond
to any mouse down events in the window's content areas. Then I can totally
dismiss the LCommander hierarchy from the drawing routines; this makes
them simpler and smaller.

In the next application, I may need all kinds of controls and editable
fields and whatnot. Then I can drag in those methods (which are neatly
grouped in the LCommander base class).

So what I'm saying, in a long-winded way, is that I see no reason to shy
away from multiple inheritance.

-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

This message printed on 100% recycled electrons.

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

>From [e-mail] (Bruce Hoult)
Date: Sat, 19 Nov 1994 12:27:18 +1300 (NZDT)
Organization: (none)

Mike Lockwood <[e-mail]> writes:
> I thought about doing something like this in the Dylan framework, but
> decided to do make the view system more like MacApp's view system.  I
> wanted all views to have the ability to handle events, so you can add
> behaviors to any view.  Providing the ability to add a behavior to any
> view is critical for supporting an interface builder that can do live
> editing of views in your running program.  I'm not sure how this could be
> implemented in a view system that has views with no event handling
> capabilities, but I suppose you could find a way to do it.

Behaviours certainly proved to be very useful in MacApp 3 and one of the most
important differences between MacApp 3 and MacApp2&TCL.  There are a lot of
situations where it's impossible to alter behaviour of some MacApp-internal
class because even if you subclass it you can't get access to the point
where it is *created* unless you reimplement a lot of other code, or alter
the source of MacApp.

It's possible, I guess, that this just indicates bad design within MacApp,
but I'm more inclined to think that the original designer simply can't
ever anticipate all possible future needs and split off a virtual function
for each one -- at some point you've got to provide a general method to
attach extra stuff to existing objects.

The minor downside of behaviours is a small performance penalty searching
sequentially through all the behaviours compared to virtual function dispatch.

The major downside is that there are no language facilities to ensure that
behaviours are checked for in every instance, and given a chance to act.
Thus the HandleEvent/DoEvent, HandleKeyDown/DoKeyDown etc dichotomy, where
HandleXXX checks for behaviours and passes the event to them if they exist,
or calls DoXXX otherwise.

This is a major source of potential errors, and would be better avoided.
But as far as I can see, Dylan works in exactly the same way as C++ in
this regard.

-- Bruce

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

>From [e-mail] (Kent Sandvik)
Date: Fri, 25 Nov 1994 14:59:13 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3aeann$[e-mail]>, Mike Lockwood
<[e-mail]> wrote:
> If you want to have a view that can draw, handle mouse clicks, respond to
> menu events and Apple events, do things at idle time (blink the cursor or
> animate a selection with marching ants), etc.  it sounds like you have to
> subclass from LPane, LCommander, LPeriodical and possibly some other
> classes.  How well has this been working out for people?  I haven't used
> MI in C++, but have heard that C++ MI has a lot of gotchas that you have
> to be aware of.  Is this ever a problem, or am I nervous about this for
> no good reason?

Ouch, my C++ arcana knowledge is pretty rusty, but what I remembered the
ordering of MI in C++ was not fully defined until the wonderful world of
C++ re-introduced a yet-another-definition of virtual, so defining virtual
in front of the mixin classes defines the ordering.

We still have the name clash issue that seems to drag on concerning a
standard; in other words if there are member functions with the same name
mixed in, let's say Initialize(), then it's really a compiler decision
which one to select from the possible ones mixed in.

Otherwise MI is sort of fun, but it has it's funny moments. It will
certainly minimize code used in various places. Then again if we have most
of the framework inside a shared library, maybe that's not an issue unless
the notion of delegation and data separation are big ones in the design of
the framework.

Cheers, Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (Lars Farm)
Date: Sat, 26 Nov 1994 13:39:03 +0100
Organization: Mid Sweden University

In article <sandvik-2511941459130001@17.255.38.246>, [e-mail]
(Kent Sandvik) wrote:

> We still have the name clash issue that seems to drag on concerning a
> standard; in other words if there are member functions with the same name
> mixed in, let's say Initialize(), then it's really a compiler decision
> which one to select from the possible ones mixed in.

With virtual bases, dominance comes in to play but all ambiguities must be
resolved by the user. As far as I know there is no undefined behavior.

> Then again if we have most
> of the framework inside a shared library, maybe that's not an issue [...]

Code size is important, but other qualities are much more important:

Coupling: High coupling (like in MA/TCL) means that you must learn,
understand and use the whole framework to use some small part. Weak
coupling (PP at least compared to MA/TCL) means you only need to learn the
thing that you want to reuse and can ignore the rest of the framework. It
can also be reused without having to drag in the rest of the framework.

Cohesion: A class that has one and only one area of responsibility (PP) is
easy to learn, explain, understand and therefor easy to reuse, a class
that does it all plus a bit of this and a bit of that (MA/TCL) is hard to
learn, explain, understand and therefor hard to reuse. It is not cohesive.

A class or _small_ module of classes that can be reused and understood on
it's own is much preferred over a class or module that can only be reused
and understood in the context of the whole framework.

IMHO these quality measures are extremely important and the very reason
that PP feels cleaner than MA/TCL. Aim for high cohesion and low coupling.
This precludes the tree aproach and leads to a forrest of small trees
independant of each other or anything else. Code bloat is nothing compared
to this even though bloated code is bad in it self.

[...] unless
> the notion of delegation and data separation are big ones in the design of
> the framework.

Lars

--
[e-mail]

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

>From [e-mail] (Erik Smith)
Date: Tue, 29 Nov 1994 12:01:08 -0800
Organization: IR/PS

Greg does not want to isolate programmers from the toolbox.  I appreciate
the way this makes powerplant smaller and simpler.  On the other hand, I
find that I am subclassing almost everything and adding my own accessors
and mutators that isolate my higher level code from the toolbox.  This
isn't really a lot of work so I'm not complaining.  I like working with
the toolbox at the same time.

What if there was another layer of subclasses provided with powerplant
that provided a friendlier API and isolated the toolbox?  Programmers
could then choose to exclude those classes when they didn't want the extra
bulk.  I don't want to see a method for every call in quickdraw for LPane,
but some basic additions to LListBox,LPopup, and other classes would be
nice.

-Erik

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

>From [e-mail] (Kent Sandvik)
Date: Sun, 04 Dec 1994 18:13:04 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Lars Farm) wrote:

> In article <sandvik-2511941459130001@17.255.38.246>, [e-mail]
> (Kent Sandvik) wrote:
>
> > We still have the name clash issue that seems to drag on concerning a
> > standard; in other words if there are member functions with the same name
> > mixed in, let's say Initialize(), then it's really a compiler decision
> > which one to select from the possible ones mixed in.
>
> With virtual bases, dominance comes in to play but all ambiguities must be
> resolved by the user. As far as I know there is no undefined behavior.

As I remember virtual base classes defines the ordering of mixing
constructors. But it does not eliminate the problem if the mixin classes
each has a member function called Initialize(void), and the code called
uses this->Initialize(). Maybe this is resolved with RTTI, it's been ages
since I last hacked C++ inside out.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (Lars Farm)
Date: Thu, 08 Dec 1994 13:41:40 +0100
Organization: Mid Sweden University

In article <sandvik-0412941813040001@17.255.38.234>, [e-mail]
(Kent Sandvik) wrote:

> > > We still have the name clash issue that seems to drag on concerning a
> > > standard; in other words if there are member functions with the same name
> > > mixed in, let's say Initialize(), then it's really a compiler decision
> > > which one to select from the possible ones mixed in.
> >
> > With virtual bases, dominance comes in to play but all ambiguities must
> > be resolved by the user. As far as I know there is no undefined behavior.
>
> As I remember virtual base classes defines the ordering of mixing
> constructors. But it does not eliminate the problem if the mixin classes
> each has a member function called Initialize(void), and the code called
> uses this->Initialize(). Maybe this is resolved with RTTI, it's been ages
> since I last hacked C++ inside out.

This has nothing to do with rtti. Rtti is about asking an object about
it's type and about checked safe down casts.

Long answer : see ARM 10.1.1, p 202 -- Ambiguities.
Short answer: Access to base class members must be unambiguous.

Your example:  class base1 { public: void Initialize(); };
               class base2 { public: void Initialize(); };
               class derived : public base1, public base2 {};

               void g( derived *d )
               {
                  d->Initialize();        // error: ambiguous
                  d->base1::Initialize(); // ok
                  d->base2::Initialize(); // ok
               }

Virtual bases have a name resolution scheme - dominance - that can resolve
some name clashes in a well defined and predictable way. Sort of 'virtual'
names.

Lars

--
[e-mail]

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

>From [e-mail] (Ken Prehoda)
Subject: QuickDraw GX Thread Safe?
Date: Tue, 06 Dec 1994 11:52:23 -0600
Organization: Univ of Wisc-Madison Dept of Biochemistry

I thought that I remember reading somewhere that QuickDraw GX is
completely reentrant.  I was hoping then, that it would be possible to
make GX calls in preemptive threads.  Unfortunately, this appears not to
be the case as GXDrawShape() will start to come up, but eventually dies in
a preemptive thread.

Does anyone know anything about this?  How about GX calls at interrupt time?

Thanks,
Ken Prehoda
Department of Biochemistry
University of Wisconsin-Madison

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

>From [e-mail] (Jon W{tte)
Date: Wed, 07 Dec 1994 16:55:29 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Ken Prehoda) wrote:

>I thought that I remember reading somewhere that QuickDraw GX is
>completely reentrant.  I was hoping then, that it would be possible to
>make GX calls in preemptive threads.  Unfortunately, this appears not to
>be the case as GXDrawShape() will start to come up, but eventually dies in
>a preemptive thread.

GX is re-entrant. That's probably one of the reasons they have
their own memory manager pool.

However, there are more things to calling stuff at interrupt
time than being re-entrant:

Lower-priority interrupts don't happen. This may include things
like Ticks being updated; I/O completing etc.

You can't cause the VM system to work, because that would make
the interrupt handler take too long, and requires I/O which in
turn is dependent on the interrupt system. Not to mention that
you may have been interrupted while I/O was going on.

You can't interface with the rest of the toolbox, because
that's not re-entrant. GXDrawShape does interface with the rest
of the toolbox, because it draws into a WindowPtr somewhere
deep down.

Cheers,

                                / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

 Please prove me wrong. I'd rather learn something new than say something old.


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

>From [e-mail] (Rob Browning)
Subject: [Q] Need help with SetGWorld.
Date: Wed, 07 Dec 1994 03:03:03 -0600
Organization: The University of Texas at Austin

I got the impression from NIM:Imaging that you are supposed to use
SetGWorld and GetGWorld instead of SetPort and GetPort for all graphics
context switches when you are using color quickdraw (p. 2-18 (among other
places)).

Now my question is, if I create a window or CGrafPort, and I then want to
make it the current port, how do I know what to pass SetGWorld in the
device parameter?   In other words, if I have a pointer to a window that I
want to make the current port, how do I know what it's device is?

I saw some sample code that did something like this:

SetGWorld(myWin,GetMainDevice());

Will this always work?  Am I guaranteed that every onscreen window's
associated device is the main device?

Thanks,

--Rob.

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

>From Paul Pharr <[e-mail]>
Date: 7 Dec 1994 20:06:51 GMT
Organization: none

In article <[e-mail]> Rob
Browning, [e-mail] writes:
>Now my question is, if I create a window or CGrafPort, and I then want to
>make it the current port, how do I know what to pass SetGWorld in the
>device parameter?   In other words, if I have a pointer to a window that
I
>want to make the current port, how do I know what it's device is?
>

GetPort & SetPort work fine if the PixMaps of both the old & new port
are actually on screen. The only time they have problems is if the port
needs to be switched between a port on a screen and a port which is an
offscreen bitmap (i.e. GWorld) or vice-versa.

For example, if the current port is an offscreen GWorld which was set
with SetGWorld, then the current GDevice is the device associated with
that GWorld. If you then used SetPort to change the port to a window on
screen, the GrafPort would be changed to the one on screen, but the
GDevice would still be the one associated with your offscreen GWorld.
Drawing under these conditions causes terrible crashes!



The rule of thumb is:

*If you need to set the port to a GWorld you have created, use SetGWorld.

*If it is possible that the current port is a GWorld and you need to
save it and set a new port, then you must use GetGWorld/SetGWorld
rather than GetPort/SetPort.

In your case, unless you are switching to or from an offscreen GWorld,
then you need not call GetGWorld/SetGWorld. GetPort/SetPort will work
fine in any version of color QuickDraw.


>I saw some sample code that did something like this:
>
>SetGWorld(myWin,GetMainDevice());
>
>Will this always work?  Am I guaranteed that every onscreen window's
>associated device is the main device?


When QuickDraw draws, part of its job in supporting multiple screens is
setting the graphics device as appropriate for drawing operations on
each screen. As long as you pass a screen device when setting the
GWorld, QuickDraw will make sure it is set correctly if the window
spans multiple screens or is on a different screen altogether.

The short answer is Yes, it will work in all cases.

Paul C. Pharr
SW Engineer

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

>From [e-mail] (Aaron Giles)
Date: Wed, 07 Dec 1994 11:40:52 -0500
Organization: Cornell University Medical College

In article <[e-mail]>,
[e-mail] (Rob Browning) wrote:

> Now my question is, if I create a window or CGrafPort, and I then want to
> make it the current port, how do I know what to pass SetGWorld in the
> device parameter?

Just pass it a nil value, and the OS will figure it out for you.  That
goes for GWorlds, too.  In fact, the only time I ever use something other
than nil for the device parameter is when I'm saving and restoring the
port by using GetGWorld/SetGWorld, in which case I just pass the device
that GetGWorld gave me.
--
Aaron Giles ([e-mail])
Power Macintosh Developer, Cornell University Medical College
JPEGView home page: http://www.med.cornell.edu/jpegview.html
JPEGView FTP site:   ftp://ftp.med.cornell.edu/pub/jpegview/

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

>From [e-mail] (Rob Browning)
Date: Wed, 07 Dec 1994 13:35:36 -0600
Organization: The University of Texas at Austin

In article <[e-mail]>,
[e-mail] (Aaron Giles) wrote:

> Just pass it a nil value, and the OS will figure it out for you.  That
> goes for GWorlds, too.  In fact, the only time I ever use something other
> than nil for the device parameter is when I'm saving and restoring the
> port by using GetGWorld/SetGWorld, in which case I just pass the device
> that GetGWorld gave me.

OK, I was hoping to treat wins, ports, and worlds the same in some code
I'm writing, but I realized that since you have to LockPixels on a world,
you can't treat it exactly the same as a port.  So is there some
(standard, i.e. supported) way, given a pointer to a port or world, to
determine which one it is?

If not, I guess I can always create a wrapper class/structure that knows
which kind of pointer it has...

Thanks,

--Rob.

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

>From [e-mail] (Greg Ewing)
Date: 7 Dec 1994 23:35:59 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Rob Browning) writes:
|> I saw some sample code that did something like this:
|>
|> SetGWorld(myWin,GetMainDevice());
|>
|> Will this always work?  Am I guaranteed that every onscreen window's
|> associated device is the main device?

Yes, I think so. There is some trickery going on which
effectively joins all your screens together and makes
them behave like a single grafport. The main screen's
grafport and its associated gdevice are the "representatives"
through which you deal with the whole collection.
Whenever you draw something while the current grafport's
pixmap is the main screen, it's also done to all the other
screens and their associated gdevices if necessary.

|> --Rob.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,          | A citizen of NewZealandCorp, a       |
Christchurch, New Zealand          | wholly-owned subsidiary of Japan Inc.|
[e-mail]         +--------------------------------------+

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

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 Dec 94 15:03:32 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <3c5gsv$[e-mail]>, [e-mail] (Greg Ewing) writes:
>
> In article <[e-mail]>, [e-mail] (Rob Browning) writes:
> |> I saw some sample code that did something like this:
> |>
> |> SetGWorld(myWin,GetMainDevice());
> |>
> |> Will this always work?  Am I guaranteed that every onscreen window's
> |> associated device is the main device?
>
> Yes, I think so.

Don't think, know. Inside Mac Vol V, page V-122: "when an application opens
a window, the window's port.portBits.baseAddr field is set to be equal to
the base address of the main screen. When QuickDraw draws into a grafPort or
cGrafPort, it compares the base address of the port to the main screen. If
they are equal, then QuickDraw might need to draw to multiple screens."

Hmm, can't find the equivalent statement inside the new "Inside Macintosh:
Imaging With QuickDraw"...

> Greg Ewing, Computer Science Dept, +--------------------------------------+
> University of Canterbury,        | A citizen of NewZealandCorp, a       |
> Christchurch, New Zealand        | wholly-owned subsidiary of Japan Inc.|
> [e-mail]       +--------------------------------------+

Lawrence "RTFM" D'Oliveiro
just another member of the invading Asian horde

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

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 Dec 94 17:28:09 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Rob Browning) writes:
> I got the impression from NIM:Imaging that you are supposed to use
> SetGWorld and GetGWorld instead of SetPort and GetPort for all graphics
> context switches when you are using color quickdraw (p. 2-18 (among other
> places)).

Not really. You only need to use Get/SetGWorld if you're doing offscreen
drawing (typically using GWorlds).

> Now my question is, if I create a window or CGrafPort, and I then want to
> make it the current port, how do I know what to pass SetGWorld in the
> device parameter?   In other words, if I have a pointer to a window that I
> want to make the current port, how do I know what it's device is?

Pass nil. For an on-screen window, Color QuickDraw will automatically
substitute the main screen device. For an off-screen GWorld, the device you
pass is ignored anyway, and the one attached to the GWorld is used.

For off-screen drawing, the sequence I recommend you use is:

    GetGWorld(PreviousGWorld, PreviousGDevice);
    SetGWorld(MyGWorld, nil);
    ... { do your offscreen drawing }
    SetGWorld(PreviousGWorld, PreviousGDevice)

Another tip: always make sure the current GWorld is set to an on-screen window
before calling WaitNextEvent or using any other toolbox calls that may draw
on-screen.

> I saw some sample code that did something like this:
>
> SetGWorld(myWin,GetMainDevice());
>
> Will this always work?  Am I guaranteed that every onscreen window's
> associated device is the main device?

Yes, it will always work, but it's easier to just pass nil.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

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

>From [e-mail] (Mark Hanrek)
Date: Thu, 8 Dec 1994 01:29:33 GMT
Organization: The Information Worskhop

In article <[e-mail]>,
[e-mail] (Rob Browning) wrote:

> I got the impression from NIM:Imaging that you are supposed to use
> SetGWorld and GetGWorld instead of SetPort and GetPort for all graphics
> context switches when you are using color quickdraw (p. 2-18 (among other
> places)).
>
> Now my question is, if I create a window or CGrafPort, and I then want to
> make it the current port, how do I know what to pass SetGWorld in the
> device parameter?   In other words, if I have a pointer to a window that I
> want to make the current port, how do I know what it's device is?
>
> I saw some sample code that did something like this:
>
> SetGWorld(myWin,GetMainDevice());
>
> Will this always work?  Am I guaranteed that every onscreen window's
> associated device is the main device?


Rob,

Good question.  Typically, dealing with ports starts in the event loop.

In your update handler, for instance, once you've extracted the port
(window) from the event, you can...

   SetPort( eventWindow );
   GetGWorld( &windowGW, &windowGD );

and keep the GDHandle ("windowGD") around for use later as needed.

The event loop will pass control to you with the current device already
set to the one that goes with the event window.  If you wanted to
determine the actual device, you would do a GetWindowDevice() function,
the source code for which is available in the DTS.lib software, either in
"utility.c" or "windows.c" found on the Developer CD, eWorld, or at
ftp.apple.com.

Do this, and you'll see how everything else falls into place.


Hope this helps.

Mark Hanrek

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

>From [e-mail] (Jay Krell)
Subject: static RoutineDescriptors
Date: 29 Nov 1994 14:02:55 GMT
Organization: Cornell University

'm having trouble making static routine descriptors/upps in code for
68K and PPC.

There is an example on p. 2-23 on IM:PPC, but it has a few problems.
It uses @ instead of &, trivial. It has incorrect typing on 68k, in
that a UniversalProcPtr is not the address of a RoutineDescriptor.

It seems to me that one simple solution is for RoutineDescriptor's to
exist in 68k, but simply be a jmp and the ProcPtr. But I guess...
that could cause problems in that you then have to find a place to
keep the stub around, but if you have to do it for PPC anyway it
shouldn't be a problem.

(p. 2-23 of IM is roughly:

RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
UniversalProcPtr myproc= &myRD;

ToolboxCall(myproc);

)

--
 -- [e-mail]

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

>From [e-mail] (Jay Krell)
Date: 29 Nov 1994 17:29:37 GMT
Organization: Cornell University

  I came up with this disgusting solution for doing static
  upp's on 68k and PPC:

  #define JMP68k 0x4EF9
  #define JMP68k_bytes 0x4E, 0xF9
  #define NOP68k 0x4E71
  #define NOP68k_bytes 0x4E, 0x71
  #define NOP68k_long 0x4E714E71

  #if USESCODEFRAGMENTS
  #define build_upp(type,proc) BUILD_ROUTINE_DESCRIPTOR(type,proc)
  #else
  #define build_upp(type,proc) {NOP68k, NOP68k_bytes, NOP68k_long, \
  NOP68k_bytes, NOP68k, NOP68k_long, NOP68k_bytes, JMP68k, proc}
  #endif

  static RoutineDescriptor scrollrd= build_upp(uppControlActionProcInfo, (ProcPtr)ScrollProc2);

  TrackControl(theControl, myPt, (ControlActionUPP) &scrollrd);

  but I'd gladly be corrected with something nicer. I should
  probably replace all the nop's with a branch, but that is
  pushing my 68k assembly ability.

--
 -- [e-mail]

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

>From [e-mail] (Ken Prehoda)
Date: Tue, 29 Nov 1994 12:31:20 -0600
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <3bfoe1$[e-mail]>, [e-mail]
(Jay Krell) wrote:

>   I came up with this disgusting solution for doing static
>   upp's on 68k and PPC:
>
>   #define JMP68k 0x4EF9
>   #define JMP68k_bytes 0x4E, 0xF9
>   #define NOP68k 0x4E71
>   #define NOP68k_bytes 0x4E, 0x71
>   #define NOP68k_long 0x4E714E71
>
>   #if USESCODEFRAGMENTS
>   #define build_upp(type,proc) BUILD_ROUTINE_DESCRIPTOR(type,proc)
>   #else
>   #define build_upp(type,proc) {NOP68k, NOP68k_bytes, NOP68k_long, \
>   NOP68k_bytes, NOP68k, NOP68k_long, NOP68k_bytes, JMP68k, proc}
>   #endif
>
>   static RoutineDescriptor scrollrd= build_upp(uppControlActionProcInfo,
(ProcPtr)ScrollProc2);
>
>   TrackControl(theControl, myPt, (ControlActionUPP) &scrollrd);

If I'm understanding your question, it's not at all that complicated:

static ControlActionUPP scrollrd;

scrollrd = NewControlDefProc(ScrollProc2);

TrackControl(theControl,myPt,scrollrd);

NewControlDefProc is conditionally compiled for 68K vs. PPC.  If compiling
for 68K, the ControlActionUPP is just a normal procptr, for PPC, it is a
routine descriptor (look in Controls.h).

Please let me know if I missed the point of your question.

Ken Prehoda
Department of Biochemistry
University of Wisconsin-Madison
[e-mail]

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

>From [e-mail] (Paul DuBois)
Date: 29 Nov 1994 14:27:05 -0600
Organization: Castra Parvulorum

>From article <3bfcaf$[e-mail]>, by [e-mail] (Jay Krell):
> 'm having trouble making static routine descriptors/upps in code for
> 68K and PPC.
>
> (p. 2-23 of IM is roughly:
>
> RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
> UniversalProcPtr myproc= &myRD;
>
> ToolboxCall(myproc);

I do something like this:

#if ppc code
RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
UniversalProcPtr myproc= &myRD;
#else   /* 68K code */
UniversalProcPtr myproc= uppproc;
#endif

ToolboxCall(myproc);

This makes myproc point to a routine descriptor for PowerPC code and
and to the function itself for 68K code.
--
Paul DuBois
[e-mail]

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

>From [e-mail] (Owen M. Hartnett)
Date: Wed, 30 Nov 1994 04:43:15 GMT
Organization: Brown University Department of Computer Science

In article <[e-mail]> [e-mail] writes:
>From article <3bfcaf$[e-mail]>, by [e-mail] (Jay Krell):
>> 'm having trouble making static routine descriptors/upps in code for
>> 68K and PPC.
>>
>> (p. 2-23 of IM is roughly:
>>
>> RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
>> UniversalProcPtr myproc= &myRD;
>>
>> ToolboxCall(myproc);
>
>I do something like this:
>
>#if ppc code
>RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
>UniversalProcPtr myproc= &myRD;
>#else  /* 68K code */
>UniversalProcPtr myproc= uppproc;
>#endif
>
>ToolboxCall(myproc);
>
>This makes myproc point to a routine descriptor for PowerPC code and
>and to the function itself for 68K code.

But the Universal Headers will do that for you anyway. They're macroed
on the 68K to just pass the procptr, and to do the right thing on the
PPC.

What you want to do is check your code for the Universal Headers, you
can do this by looking for #ifdef __CONDITIONALMACROS__

Here's a little standard file hacking:

// definitions
#ifdef __CONDITIONALMACROS__
        FileFilterUPP           myFolderFilterUPP;
        ModalFilterUPP  myFolderEventsUPP;
        DlgHookUPP              myDlgHookUPP;
#endif

// code
#ifdef __CONDITIONALMACROS__
        myFolderFilterUPP = NewFileFilterProc(FolderFilter);
        myFolderEventsUPP = NewModalFilterProc(FolderEvents);
        myDlgHookUPP = NewDlgHookYDProc(FolderItems);
        SFPGetFile(where, (StringPtr)0, myFolderFilterUPP, -1, 0, myDlgHookUPP,
                   &reply, 20001, myFolderEventsUPP);
        DisposeRoutineDescriptor(myFolderFilterUPP);
        DisposeRoutineDescriptor(myFolderEventsUPP);
        DisposeRoutineDescriptor(myDlgHookUPP);
#else
        SFPGetFile(where, (StringPtr)0, (ProcPtr) FolderFilter, -1, 0, FolderItems,
                   &reply, 20001, (ProcPtr) FolderEvents);
#endif

-Owen

--
Owen Hartnett                           [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
                without knowledge, of things without parallel."
                        -Ambrose Bierce - The Devil's Dictionary

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

>From [e-mail] (Paul DuBois)
Date: 30 Nov 1994 09:48:56 -0600
Organization: Castra Parvulorum

>From article <[e-mail]>, by [e-mail] (Owen M. Hartnett):
> In article <[e-mail]> [e-mail] writes:
>>From article <3bfcaf$[e-mail]>, by [e-mail] (Jay Krell):
>>> 'm having trouble making static routine descriptors/upps in code for
>>> 68K and PPC.
>>>
>>> (p. 2-23 of IM is roughly:
>>>
>>> RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
>>> UniversalProcPtr myproc= &myRD;
>>>
>>> ToolboxCall(myproc);
>>
>>I do something like this:
>>
>>#if ppc code
>>RoutineDescriptor myRD= BUILD_ROUTINE_DESCRIPTOR(upptype, uppproc);
>>UniversalProcPtr myproc= &myRD;
>>#else /* 68K code */
>>UniversalProcPtr myproc= uppproc;
>>#endif
>>
>>ToolboxCall(myproc);
>>
>>This makes myproc point to a routine descriptor for PowerPC code and
>>and to the function itself for 68K code.
>
> But the Universal Headers will do that for you anyway. They're macroed
> on the 68K to just pass the procptr, and to do the right thing on the
> PPC.

The Universal Headers will do *what* for you anyway?  Define
BUILD_ROUTINE_DESCRIPTOR for the 68K case?  Unless I'm missing something,
that macro isn't conditionally defined differently for 68K vs. PPC
code.

The example you give below works for the use of routine descriptor
generating functions that are called on the fly.  The original posting
asked for a method for static routine descriptor allocation.

> What you want to do is check your code for the Universal Headers, you
> can do this by looking for #ifdef __CONDITIONALMACROS__
>
> Here's a little standard file hacking:
>
> // definitions
> #ifdef __CONDITIONALMACROS__
>       FileFilterUPP           myFolderFilterUPP;
>       ModalFilterUPP  myFolderEventsUPP;
>       DlgHookUPP              myDlgHookUPP;
> #endif
>
> // code
> #ifdef __CONDITIONALMACROS__
>       myFolderFilterUPP = NewFileFilterProc(FolderFilter);
>       myFolderEventsUPP = NewModalFilterProc(FolderEvents);
>       myDlgHookUPP = NewDlgHookYDProc(FolderItems);
>       SFPGetFile(where, (StringPtr)0, myFolderFilterUPP, -1, 0, myDlgHookUPP,
>                  &reply, 20001, myFolderEventsUPP);
>       DisposeRoutineDescriptor(myFolderFilterUPP);
>       DisposeRoutineDescriptor(myFolderEventsUPP);
>       DisposeRoutineDescriptor(myDlgHookUPP);
> #else
>       SFPGetFile(where, (StringPtr)0, (ProcPtr) FolderFilter, -1, 0, FolderItems,
>                  &reply, 20001, (ProcPtr) FolderEvents);
> #endif
--
Paul DuBois
[e-mail]

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

>From [e-mail] (Francois Pottier)
Date: 30 Nov 1994 18:28:36 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <[e-mail]>,
Paul DuBois <[e-mail]> wrote:

>> But the Universal Headers will do that for you anyway. They're macroed
>> on the 68K to just pass the procptr, and to do the right thing on the
>> PPC.
>
>The Universal Headers will do *what* for you anyway?  Define
>BUILD_ROUTINE_DESCRIPTOR for the 68K case?  Unless I'm missing something,
>that macro isn't conditionally defined differently for 68K vs. PPC
>code.

Paul is right. BUILD_ROUTINE_DESCRIPTOR is defined only on the PPC.
Using BUILD_ROUTINE_DESCRIPTOR instead of NewWhateverUPP() is better
because it doesn't cause any heap allocation. I remember discussing
this topic with Zalman Stern a while ago on csmp, he defines a macro
that simply returns a function pointer on 68k and builds a static
routine descriptor using BUILD_ROUTINE_DESCRIPTOR on PPC.



--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

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

>From [e-mail] (Jeff Pek)
Date: 30 Nov 1994 18:24:11 GMT
Organization: U of Mich (MBA)

In article <[e-mail]>
[e-mail] (Paul DuBois) writes:

> >>This makes myproc point to a routine descriptor for PowerPC code and
> >>and to the function itself for 68K code.
> >
> > But the Universal Headers will do that for you anyway. They're macroed
> > on the 68K to just pass the procptr, and to do the right thing on the
> > PPC.
>
> The Universal Headers will do *what* for you anyway?  Define
> BUILD_ROUTINE_DESCRIPTOR for the 68K case?  Unless I'm missing something,
> that macro isn't conditionally defined differently for 68K vs. PPC
> code.

Univ Headers define macros (that are conditionally defined) to create
UPPs for all system callbacks (e.g. ControlActionUPP). You don't have
to have any #ifxxx junk in your code, as the appropriate univ hdr file
will take care of that.

> The example you give below works for the use of routine descriptor
> generating functions that are called on the fly.  The original posting
> asked for a method for static routine descriptor allocation.

To create a static upp, you just have to do (something like):

pascal Boolean fcn(...);
static xxxUPP = NewxxxProc(fcn);

Jeff
- -------------------------------------------
Jeff Pek                       [e-mail]
Emerald Intelligence / University of Michigan

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

>From [e-mail] (Christian E. Hopps)
Date: 30 Nov 1994 18:58:22 GMT
Organization: University of Michigan EECS Dept.

Jeff Pek ([e-mail]) wrote:
[...]
: To create a static upp, you just have to do (something like):

: pascal Boolean fcn(...);
: static xxxUPP = NewxxxProc(fcn);

Heh, obviously someone whose roots are in C++ (as opposed to C) :)
This doesn't work in C BTW.  Other solutions have been posted..

Chris.

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

>From [e-mail] (Paul DuBois)
Date: 30 Nov 1994 15:43:21 -0600
Organization: Castra Parvulorum

>From article <3big0b$[e-mail]>, by [e-mail] (Jeff Pek):
> In article <[e-mail]>
> [e-mail] (Paul DuBois) writes:
>
>> >>This makes myproc point to a routine descriptor for PowerPC code and
>> >>and to the function itself for 68K code.
>> >
>> > But the Universal Headers will do that for you anyway. They're macroed
>> > on the 68K to just pass the procptr, and to do the right thing on the
>> > PPC.
>>
>> The Universal Headers will do *what* for you anyway?  Define
>> BUILD_ROUTINE_DESCRIPTOR for the 68K case?  Unless I'm missing something,
>> that macro isn't conditionally defined differently for 68K vs. PPC
>> code.
>
> Univ Headers define macros (that are conditionally defined) to create
> UPPs for all system callbacks (e.g. ControlActionUPP). You don't have
> to have any #ifxxx junk in your code, as the appropriate univ hdr file
> will take care of that.

Not for BUILD_ROUTINE_DESCRIPTOR, which isn't a callback and isn't
conditionally defined.

>> The example you give below works for the use of routine descriptor
>> generating functions that are called on the fly.  The original posting
>> asked for a method for static routine descriptor allocation.
>
> To create a static upp, you just have to do (something like):
>
> pascal Boolean fcn(...);
> static xxxUPP = NewxxxProc(fcn);

Well, perhaps I understand these issues less well than I *already* thought
I didn't understand them :-), but how would this work?  Wouldn't it allocate
a pointer object on the heap, as opposed to static allocation of the routine
descriptor?  (The latter being what is desired for the question that began
this thread.)


Another nice question is how to get the right sort of callback when you
want to generate either PPC or 68K code, *and* you want people that don't
have the universal headers to be able to compile the source.  (The latter
would be generating 68K code only, of course.)
--
Paul DuBois
[e-mail]

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

>From [e-mail] (Owen M. Hartnett)
Date: Thu, 1 Dec 1994 02:41:55 GMT
Organization: Brown University Department of Computer Science

In article <[e-mail]> [e-mail] writes:
>From article <3big0b$[e-mail]>, by [e-mail] (Jeff Pek):
>> In article <[e-mail]>
>> [e-mail] (Paul DuBois) writes:
>>
>>> >>This makes myproc point to a routine descriptor for PowerPC code and
>>> >>and to the function itself for 68K code.
>>> >
>>> > But the Universal Headers will do that for you anyway. They're macroed
>>> > on the 68K to just pass the procptr, and to do the right thing on the
>>> > PPC.
>>>
>>> The Universal Headers will do *what* for you anyway?  Define
>>> BUILD_ROUTINE_DESCRIPTOR for the 68K case?  Unless I'm missing something,
>>> that macro isn't conditionally defined differently for 68K vs. PPC
>>> code.
>>
>> Univ Headers define macros (that are conditionally defined) to create
>> UPPs for all system callbacks (e.g. ControlActionUPP). You don't have
>> to have any #ifxxx junk in your code, as the appropriate univ hdr file
>> will take care of that.
>
>Not for BUILD_ROUTINE_DESCRIPTOR, which isn't a callback and isn't
>conditionally defined.
>
>>> The example you give below works for the use of routine descriptor
>>> generating functions that are called on the fly.  The original posting
>>> asked for a method for static routine descriptor allocation.
>>
>> To create a static upp, you just have to do (something like):
>>
>> pascal Boolean fcn(...);
>> static xxxUPP = NewxxxProc(fcn);
>
>Well, perhaps I understand these issues less well than I *already* thought
>I didn't understand them :-), but how would this work?  Wouldn't it allocate
>a pointer object on the heap, as opposed to static allocation of the routine
>descriptor?  (The latter being what is desired for the question that began
>this thread.)
>
>
>Another nice question is how to get the right sort of callback when you
>want to generate either PPC or 68K code, *and* you want people that don't
>have the universal headers to be able to compile the source.  (The latter
>would be generating 68K code only, of course.)

Hmmm... As it turned out to be a deeper problem than I originally thought, I
went back and read Develop 16's explanation, which is less than clear.

It was my assumption that you could allocate the static routine
descriptor, and, under 68K, it would do the right thing. Indeed the article
somewhat implies that this is so (by stating you could either allocate a UPP
or use BUILDROUTINEDESCRIPTOR for static.

But looking at MixedMode.h, there's only one definition for it, and it
builds a full Routine Desciptor record. Now the question is, if you use
this record on a 68K, will you live to tell of it? (i.e. is the code
smart enough to know what you're doing.)

-Owen



--
Owen Hartnett                           [e-mail]
"FAITH, n. Belief without evidence in what is told by one who speaks
                without knowledge, of things without parallel."
                        -Ambrose Bierce - The Devil's Dictionary

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

>From [e-mail] (Ken Prehoda)
Date: Thu, 01 Dec 1994 13:26:43 -0600
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <[e-mail]>, [e-mail] (Owen M.
Hartnett) wrote:

> But looking at MixedMode.h, there's only one definition for it, and it
> builds a full Routine Desciptor record. Now the question is, if you use
> this record on a 68K, will you live to tell of it? (i.e. is the code
> smart enough to know what you're doing.)
>
> -Owen

No, you won't.  The 68K expects a procptr to be a procptr.  If you give it
a routine descriptor, it will jump to the first entry in the descriptor,
which is _MixedModeMagic and is not implemented on 68K.  The CFM for 68k
may change this.

I haven't actually done this so...

Ken Prehoda
Department of Biochemistry
University of Wisconsin-Madison
[e-mail]

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

>From [e-mail] (Anton Rang)
Date: 02 Dec 1994 02:57:44 GMT
Organization: Trillium Research, Inc.

In article <3big8k$[e-mail]> [e-mail] (Francois Pottier) writes:
>Paul is right. BUILD_ROUTINE_DESCRIPTOR is defined only on the PPC.
>Using BUILD_ROUTINE_DESCRIPTOR instead of NewWhateverUPP() is better
>because it doesn't cause any heap allocation.

  If you're writing an accelerated code resource (e.g. a WDEF, CDEF,
or other resource called using 68K calling conventions), there's an
even better reason to use a static routine descriptor: the code
fragment manager will automatically make it point to the right place
if your code gets relocated.

  Of course, most accelerated resources are called at memory-safe
times, so you can allocate and deallocate a routine descriptor
dynamically, but....
--
Anton Rang ([e-mail])

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

>From Joe Francis <[e-mail]>
Date: 7 Dec 1994 16:04:32 GMT
Organization: Smooth Roo Software

#if USESROUTINEDESCRIPTORS
        RoutineDescriptor RBApp_DialogFilterProc_RD =
                BUILD_ROUTINE_DESCRIPTOR(uppFileFilterYDProcInfo,&OifFileHook);
        #define RBDIALOGFILT (FileFilterYDUPP)&RBApp_DialogFilterProc_RD
#else
        #define RBDIALOGFILT (FileFilterYDUPP)OifFileHook
#endif


- ------------------------------------------------------------------------
"When we gave Bill Gates his first demo of the Macintosh, the first
question he asked was "What kind of hardware do you use for the cursor?"
-Andy Hertzfeld, at the MacHack '94 Keynote address
- ------------------------------------------------------------------------

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

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