Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-109.txt

Text File | 1992-12-31 | 42.1 KB | 1,076 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 09 Jun 92       Volume 1 : Issue 109

Today's Topics:

    LaserWriter Reboot Code in PS?
    Floating Windowiods and MacApp 3.0
    Apple User Interface Police
    Offscreen graphics sans Color QuickDraw?
    Finding the VolID and DirID of the App
    ics#/ics4/ics8 in menus
    Tech Note or Other Apple Doc on MIDI
    AppleEvents and TCL
    Drag and Drop onto a document?


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

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

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

The digest is a collection of articles 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.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to           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
virus order sentences of words in signature the rearranges This.

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

From: [e-mail] (Michael Peterson)
Subject: Floating Windowiods and MacApp 3.0
Date: 28 Apr 92 23:57:34 GMT
Organization: University of Southern California, Los Angeles, CA



PROBLEM:
    I'm trying to get a windowiod up in MapApp 3.0 and am having
problems. Has anyone done this before and if so how.

    I am calling InitUFloatWindow, changing the window resource to the
TFLOATWINDOW class, including the "FloatWindow.rsrc" and everything else I can think of.

RESULTS:
    Every little.  The NewTemplateWindow call doesn't return nil,
but the window does not come up. while other normal windows do.


                Please help.
                A Man without a Window.

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

From: [e-mail] (Kent Sandvik)
Date: 9 May 92 02:20:03 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Michael
Peterson) writes:
> PROBLEM:
>     I'm trying to get a windowiod up in MapApp 3.0 and am having
> problems. Has anyone done this before and if so how.
>
>     I am calling InitUFloatWindow, changing the window resource to the
> TFLOATWINDOW class, including the "FloatWindow.rsrc" and everything else I can
think of.
>
> RESULTS:
>     Every little.  The NewTemplateWindow call doesn't return nil,
> but the window does not come up. while other normal windows do.

There's a sample on ftp.apple.com, somewhere inside the snippets directory,
called Windoid. It's a MacApp 3.0a2 based sample that shows how to create
tear-off
menu windoids.

Yes, I know, I should clean up the code for MacApp 3.0 final, and that's
exactly what I'm working on just now. Later (don't know when) my MouseInfo
Behavior sample should also appear on the ftp server, and this one also
has a floating window palette.

Cheers,
Kent
PS: Keith, how many grammar errors?
PSS: "Reality is what refuses to go away when I stop believing in it."

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

From: [e-mail] (Matt Mora)
Subject: Apple User Interface Police
Date: 27 Apr 92 16:42:18 GMT
Organization: SRI International, Menlo Park, California


I thought I read somewhere that AUIP frowned upon changing the cursor location
on the user. (ie moving the cursor over the default button like they do
on the Sun Platform) After searching the technotes and the Developer CD's
I could not find this reference. Does this guideline exsist or am I making it
up?

Thanks

Matt








- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

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

From: [e-mail] (Quinn "The Eskimo!")
Date: 28 Apr 92 02:14:34 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Matt Mora) writes:
>
> I thought I read somewhere that AUIP frowned upon changing the cursor location
> on the user. (ie moving the cursor over the default button like they do
> on the Sun Platform) After searching the technotes and the Developer CD's
> I could not find this reference. Does this guideline exsist or am I making it
> up?

I think the User Interface Thought Police didn't put that recommendation in
because they couldn't believe anyone could be that *stupid*.  But Sun
Microsystems astound the world again.  I think you can put jumping the
pointer about in the same basket as Sun's other 'crowning achievements' like:

o talk(1) still being host byte order dependent
o Sun workstations still using all zero's for broadcasts

This leads me to question whether Sun is getting technical advice from
Microsloth or vice versa (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who feels safe flaming Sun in a Mac group (-:

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

From: [e-mail] (Larry Rosenstein)
Date: 28 Apr 92 22:43:22 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>
>
> I thought I read somewhere that AUIP frowned upon changing the cursor location

I guess there's no specific guideline about this, perhaps since there's no
official system call to move the pointer.  (Pointer is the official name.)  The
closest would be the statement that users want to feel that they are in charge
of the computer's activities.

- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

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

From: [e-mail] (Andrew Loewenstern)
Date: 28 Apr 92 20:17:28 GMT
Organization: Cube Technologies, Inc.

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>
>I thought I read somewhere that AUIP frowned upon changing the cursor location
>on the user. (ie moving the cursor over the default button like they do
>on the Sun Platform) After searching the technotes and the Developer CD's
>I could not find this reference. Does this guideline exsist or am I making it
>up?

I don't remember seeing this explicitly stated somewhere, but it would
make sense for this to be a nono.  Many people would get confused if
the cursor started moving around on them.


andrew
- --
[e-mail]
Andrew Loewenstern            |  "listen: there's a hell of a good universe
Cube Technologies, Inc.       |   next door; let's go." --- e.e. cummings

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

From: [e-mail] (Thomas A. Russ)
Date: 29 Apr 92 16:50:02 GMT
Organization: USC-ISI

In article <...> [e-mail] (Andrew Loewenstern) writes:

   In article <...> [e-mail] (Matt Mora) writes:
   >
   >I thought I read somewhere that AUIP frowned upon changing the
   >cursor location on the user. (ie moving the cursor over the
   >default button like they do on the Sun Platform) After searching
   >the technotes and the Developer CD's I could not find this
   >reference. Does this guideline exsist or am I making it up?

   I don't remember seeing this explicitly stated somewhere, but it would
   make sense for this to be a nono.  Many people would get confused if
   the cursor started moving around on them.

I second this opinion.  I hate it when the Sun moves my cursor for me.
I start trying to move it and end up moving it off the button and then
back on again.  Unless the cursor is hidden because the user has been
doing something completely different, please don't move it.  The Apple
User Interface philosophy is that the user is in control of the
machine, not the other way around.
- --

Thomas A. Russ                               [e-mail]
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292          [phone]

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

From: [e-mail] (Ramon M. Felciano)
Date: 29 Apr 92 19:26:09 GMT
Organization: SUMMIT (Stanford Univ. Medical Media and Information


I agree whole heartedly -- the cursor should always be left completely in
the user's control. Quickkeys sequences (macros) have the cursor jump all
over the place, and it is >very< distressing!

Ramon M. Felciano
Associate Director, SUMMIT
Stanford University Medical Media and Information Technologies

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

From: [e-mail]
Date: Thu, 30 Apr 1992 11:42:01 GMT
Organization: Actrix Information Exchange

I don't know whether it still does (and I don't have it on this machine
to check) but old versions of Excel used to move the cursor by themselves.

What happened (deduced from playing with it) was that Microsoft made dragging
the scroll bar thumbs non-linear for better control of small movements around
the spreadsheet.  It semed to be roughly quadratic: if you were in the middle
of the sheet and dragged the thumb to the 75% mark (i.e. half way from where
you were to the end) then you'd actually move a quarter of the way towards
the end (i.e. to 62.5% of the way in the document).

The problem with this is of course that now that you're 62.5% of the way
through the document, the scroll bar thumb should also be 62.5% of the way.
So when you released the mouse button they snapped the thumb back to
the 62.5% mark, and at the same time moved the mouse pointer by the same
amount so that it was still positioned over the thumb, ready to drag the
thumb again.

Now I don't know whether or not it was a quadratic law or some other
formula, but I do know that the pointer and thumb both snapped to a
different position when you released the button in the way described
and most people didn't notice it.

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

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

From: [e-mail] (David Morgenstern)
Date: 1 May 92 15:34:46 GMT
Organization: San Francisco State University

Who is in charge of the Interface Police now that Tog, Dr. Bob, and
a bunch of other Human Interfacers have gone over to SUN? Who's
running the store (or station)?

daviD
- --
*****     David Morgenstern (a.k.a. BMUG CheerLeader)     *****
*     CIS: 72030,1607   AOL: daviD eM   FAX: [phone]     *

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

From: [e-mail] (Kevin Vail)
Date: 30 Apr 92 15:36:47 GMT
Organization: DB Resources, Inc., Vienna, VA

In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:
>In article <[e-mail]>, [e-mail] (Matt Mora) wrote:
>> I thought I read somewhere that AUIP frowned upon changing the cursor
>> location
>
>I guess there's no specific guideline about this, perhaps since there's no
>official system call to move the pointer.  (Pointer is the official name.)  The
>closest would be the statement that users want to feel that they are in charge
>of the computer's activities.

Vision does this (moves the pointer) when you select one of their pop-up
menu things, and what's more they put it back where it was when you exit.
It's very disorienting even when you're expecting it.

+----------------------------------+-------------------------------------+
|  |<evin |\/|ichael \/ail         |  ...and the only measure            |
|  [e-mail]                  |     of your words and your deeds    |
|  [e-mail]  |  will be the love you leave behind  |
|  uunet!vailbox!kevin             |     when you're gone...             |
+----------------------------------+-------------------------------------+

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

From: [e-mail] (Kent Sandvik)
Date: 4 May 92 21:59:31 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (David
Morgenstern) writes:
>
> Who is in charge of the Interface Police now that Tog, Dr. Bob, and
> a bunch of other Human Interfacers have gone over to SUN? Who's
> running the store (or station)?

..maybe they didn't have much challenges anymore inside Apple,
and they saw a fruitful environment where interfaces are still
primitive :-).

Just joking.
Kent

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

From: [e-mail] (Thad Humphries)
Date: 5 May 92 03:37:26 GMT


  > I guess there's no specific guideline about this, perhaps since there's
  > no official system call to move the pointer.  (Pointer is the official
  > name.)  The closest would be the statement that users want to feel that
  > they are in charge of the computer's activities.
  >
  KV> Vision does this (moves the pointer) when you select one of their
  KV> pop-up menu things, and what's more they put it back where it was when
  KV> you exit. It's very disorienting even when you're expecting it.

One reason that SunView and XView/OPENLOOK does this is that the Sun's screen is
to large that it is very nice not to have to find your cursor for a small dialog
box.

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

From: [e-mail] (& Wise)
Date: 6 May 92 14:43:03 GMT
Organization: Organization?  I thought entropy would take care of that...

In article <[e-mail]> [e-mail] (Thad Humphries) writes:
 >    > I guess there's no specific guideline about this, perhaps since there's
 >    > no official system call to move the pointer.  (Pointer is the official
 >    > name.)  The closest would be the statement that users want to feel that
 >    > they are in charge of the computer's activities.
 >    >
 >    KV> Vision does this (moves the pointer) when you select one of their
 >    KV> pop-up menu things, and what's more they put it back where
 >    KV> it was when KV> you exit. It's very disorienting even when
 >    KV> you're expecting it.
 >
 >  One reason that SunView and XView/OPENLOOK does this is that the
 >  Sun's screen is to large that it is very nice not to have to find
 >  your cursor for a small dialog box.

I use X on a monochrome DECstation (1280x1024 -- 19" VR319) which is
slightly larger than the display on the Sun 3/60, but I only have
trouble finding the pointer if the system has moved it (e.g.,
Interleaf). Display size does not seem to be a factor for all users.

Unfortunately, I cannot find any references to formal studies on the
issue.  I did find references in the DEC XUI and Motif style guides.
Since the Motif guide is derived from XUI's, I only quote the Motif
one:
        2.2.3.2 The Pointer
        ...
        Your application should only interpret the mouse pointer
        position; it should not attempt to change it. To do so would
        violate users' trust in the consistency of your program and
        their sense of control. Also, changing the mouse pointer
        location may create problems in applications that use absolute
        location devices (like graphics tablets).

        /s
- --
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ [e-mail] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\

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

From: [e-mail] (Kent Sandvik)
Date: 7 May 92 23:42:20 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Quinn "The Eskimo!") writes:
> In article <[e-mail]>, [e-mail] (Matt Mora) writes:
> >
> > I thought I read somewhere that AUIP frowned upon changing the cursor
location
> > on the user. (ie moving the cursor over the default button like they do
> > on the Sun Platform) After searching the technotes and the Developer CD's
> > I could not find this reference. Does this guideline exsist or am I making
it
> > up?

> I think the User Interface Thought Police didn't put that recommendation in
> because they couldn't believe anyone could be that *stupid*.  But Sun
> Microsystems astound the world again.  I think you can put jumping the
> pointer about in the same basket as Sun's other 'crowning achievements' like:

No wonder they need Tog more than we nowadays :-).

Cheers,
Kent

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

Subject: Offscreen graphics sans Color QuickDraw?
From: [e-mail]
Date: 7 May 92 15:24:35 EST
Organization: Wright State University

I'm in a bit of trouble with System 7 offscreen graphics world routines
on Macs without ColorQuickDraw.

I'm using THINK Pascal 4.0.1 under System 7.0 (tuneup 1.1.1). I create
an offscreen world and lock it without error:

  SetRect(rWorld, 0, 0, 550, 550);
  err := NewGWorld(offWorldPtr, 0, rWorld, nil, nil, []);
  locked := LockPixels(MyGetPixMap(offWorldPtr));

I call GetGWorldPixMap only when appropriate:

  function MyGetPixMap (gwPtr: GWorldPtr): PixMapHandle;
  begin
    if hasGGWPM then {according to Q & A stack}
      MyGetPixMap := GetGWorldPixMap(gwPtr)
    else
      MyGetPixMap := gwPtr^.portPixMap;
  end;

I initialize offWorld without incident:

  GetGWorld(savePort, saveGDH);
  SetGWorld(offWorldPtr, nil);
  rWorld := offWorldPtr^.portRect;
  EraseRect(rWorld);
  if hasCQD then {ColorQuickDraw only stuff};
  SetGWorld(savePort, saveGDH);

I repeatedly draw off-screen then on-screen:

  GetGWorld(savePort, saveGDH);
  GetForeColor(saveColor);
  if hasCQD then
    RGBForeColor(deltaColor);
  SetGWorld(offWorldPtr, nil); {draw offscreen}
  MoveTo(ix, iy);
  Line(0, 0);
  ix := ix - left; {translate to screen}
  iy := iy - top;
  SetGWorld(savePort, saveGDH); {draw onscreen}
  MoveTo(ix, iy);
  Line(0, 0); {<-----Bomb: illegal instruction in an 'scod' resource}
  RGBForeColor(saveColor);
  PenNormal;

This all works fine on a Mac II, IIcx, IIfx, and Classic II; it
survives heap scrambling and strict discipline; it bombs on a
Classic!? I'm pretty sure I'm not generating any 020/030 instructions.
Still, I'm doing _something_ to make the Classic think it's safe to
execute such code.

Any thoughts on this? Thanks in advance.

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

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

From: [e-mail] (Jack Herrington)
Subject: Finding the VolID and DirID of the App
Date: 1 May 92 20:12:50 GMT
Organization: University of Miami Medical School

Anyone got a good way to find the directory ID and volume ID of the
application.  This is useful when the user launches from a document
in a different directory and your app depends on files that are in the
same directory as the app...

Any help?
- --
"Electric word 'life', it means forever and that's a might long time.  But I'm
 here to tell yah, there's something else... The after-life, a word of
 never-ending happiness, you can always see the sun, day or night.  So when you
 call up that shrink in Beverly hills, you know the one, Dr. everything-we-all-

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

From: [e-mail] (Jack Herrington)
Date: 1 May 92 21:21:47 GMT
Organization: University of Miami Medical School

[e-mail] (Jack Herrington) writes:
: Anyone got a good way to find the directory ID and volume ID of the
: application.  This is useful when the user launches from a document
: in a different directory and your app depends on files that are in the
: same directory as the app...

Great, I get to answer my own question.  (I gave up a little too early on
this one).  Here is the solution:

    ////
    //// Get the home directory of the application
    ////

Boolean GetApplicationHome(short *theVolID,long *theDirID)
{
    FCBPBRec ourRec;
    Boolean retVal;
    short ourVolID,ourResID;
    long ourDirID;

        //// Load the return variables initially with -1

    *theVolID = (-1);
    *theDirID = (-1);

        //// Store the refNum of the current resource file
        //// (at opening time, this will be the applications
        //// resource fork)

    ourResID = CurResFile();

        //// Figure that we will be successful

    retVal = true;

        //// Get the volume ID of the resource fork

    if ( GetVRefNum(ourResID,&ourVolID) != noErr ) return false;

        //// Put together a 'FCBPBRec' record to ask for the dirID

    ourRec.qLink = 0L;
    ourRec.qType = 0;
    ourRec.ioTrap = 0L;
    ourRec.ioCmdAddr = 0L;
    ourRec.ioCompletion = 0L;
    ourRec.ioFCBIndx = 0;
    ourRec.ioVRefNum = ourVolID;
    ourRec.ioRefNum = ourResID;
    ourRec.ioNamePtr = 0L;

        //// Send the record synchronously and store the return value

    if ( PBGetFCBInfo(&ourRec,false) == noErr )
        ourDirID = ourRec.ioFCBParID;
    else retVal = false;

        //// Store the values in the variable passed

    if ( retVal == true )
    {
        *theVolID = ourVolID;
        *theDirID = ourDirID;
    }

        //// Return if we were successful

    return retVal;
}
- --
"Electric word 'life', it means forever and that's a might long time.  But I'm
 here to tell yah, there's something else... The after-life, a word of
 never-ending happiness, you can always see the sun, day or night.  So when you
 call up that shrink in Beverly hills, you know the one, Dr. everything-we-all-

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

From: [e-mail] (Jeremy Roussak)
Date: 5 May 92 19:24:43 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Jack Herrington) writes:

>Anyone got a good way to find the directory ID and volume ID of the
>application.  This is useful when the user launches from a document
>in a different directory and your app depends on files that are in the
>same directory as the app...

>Any help?

Use PBGetFCBInfo (IM IV-179) with ioRefNum equal to
CurResFile().  This works nicely.

Jeremy Roussak

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

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Wed, 6 May 1992 06:43:17 GMT

In article <[e-mail]>, [e-mail] (Jeremy Roussak) writes:

> >Anyone got a good way to find the directory ID and volume ID of the
> >application.  This is useful when the user launches from a document
> >in a different directory and your app depends on files that are in the
> >same directory as the app...

> Use PBGetFCBInfo (IM IV-179) with ioRefNum equal to
> CurResFile().  This works nicely.

I preffer
oe:=GetVol(wdrn,nil)
oe:=GetWDInfo(wdrn,vrn,dirID,procID);

I tried using the wdrn in the GetAppParms instead of GetVol, but it failed,
anyone know why GetAppParms wouldnt work (under System 7)?

Have fun all,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



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

From: [e-mail] (Keith Rollin)
Date: 7 May 92 23:07:55 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Peter N Lewis) writes:
>
> In article <[e-mail]>, [e-mail] (Jeremy
Roussak) writes:
>
> > >Anyone got a good way to find the directory ID and volume ID of the
> > >application.  This is useful when the user launches from a document
> > >in a different directory and your app depends on files that are in the
> > >same directory as the app...
>
> > Use PBGetFCBInfo (IM IV-179) with ioRefNum equal to
> > CurResFile().  This works nicely.
>
> I preffer
> oe:=GetVol(wdrn,nil)
> oe:=GetWDInfo(wdrn,vrn,dirID,procID);
>

I prefer:

err = HGetVol(nil, &vRefNum, &dirID);

not only because it's one call shorter, but also because it's in C   :-)

Remember, this call must be made _before_ doing anything that could change the
default directory. If you need to find out what directory you are in at any old
time, then the GetFCBInfo trick (like the way Jack did it in his follow-up
posting) is OK.

>I tried using the wdrn in the GetAppParms instead of GetVol, but it failed,
>anyone know why GetAppParms wouldnt work (under System 7)?

GetAppParms doesn't return the same information as GetVol. The former returns
the name and resRefNum of the running application. The latter returns the
vRefNum or wdRefNum of the default directory or volume.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


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

From: [e-mail] (Martin Friedrich)
Date: 8 May 92 06:57:09 GMT
Organization: University of Oldenburg, Germany

[e-mail] (Peter N Lewis) writes:

>In article <[e-mail]>, [e-mail] (Jeremy Roussak) writes:

>> >Anyone got a good way to find the directory ID and volume ID of the
>> >application.  This is useful when the user launches from a document
>> >in a different directory and your app depends on files that are in the
>> >same directory as the app...

>> Use PBGetFCBInfo (IM IV-179) with ioRefNum equal to
>> CurResFile().  This works nicely.

>I preffer
>oe:=GetVol(wdrn,nil)
>oe:=GetWDInfo(wdrn,vrn,dirID,procID);

[...]
Another way is to get the information via the Process Manager (Sys7,of course)
from the processInfo-record of the application.
- --
LLaP
       Martin Friedrich

- -----------------------------------------------------------------------------
                         |"I never will understand
REAL      Martin Friedrich   (CS-Student)    | humans ..."
NICK      jupp                               | -- Spock, Patterns of Force
UUCP      friedrich@uniol                    --------------------------------
DOMAIN    [e-mail]
HOME      Straekweg 1 , 2986 Leezdorf

     You can call me by my nickname,my nickname is ... SIR !
- -----------------------------------------------------------------------------

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

From: [e-mail] (Jon W{tte)
Date: 8 May 92 11:01:03 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Keith Rollin) writes:

   err = HGetVol(nil, &vRefNum, &dirID);

   not only because it's one call shorter, but also because it's in C   :-)

Ah, but you+ll get a wdRefNum in the vRefNum parameter, so you can't
use that for testing which volume you're on. You still have to
convert the wdRefNum to a vRefNum/dirID pair and discard the dirID
from that conversion.

Why would I want to compare vRefNums, you say ? Well, I use the
"relative" feature of aliases.

- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

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

From: [e-mail] (Keith Rollin)
Date: 8 May 92 22:49:59 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Jon W{tte) writes:
>
> > [e-mail] (Keith Rollin) writes:
>
>    err = HGetVol(nil, &vRefNum, &dirID);
>
>    not only because it's one call shorter, but also because it's in C   :-)
>
> Ah, but you+ll get a wdRefNum in the vRefNum parameter, so you can't
> use that for testing which volume you're on. You still have to
> convert the wdRefNum to a vRefNum/dirID pair and discard the dirID
> from that conversion.

Urp. I forgot about that. Well, how about letting me scrape together any last
shreds of dignity by suggesting calling PBHGetVol (I never make high-level calls
anyway). That way, you can look at the ioWDVRefNum field to get the real
vRefNum.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

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

From: [e-mail] (Rich Siegel)
Subject: ics#/ics4/ics8 in menus
Date: 5 May 92 00:33:59 GMT
Organization: GCC Technologies

I know that by putting the appropriate value in the itemCmd field, a 'sicn'
resource can be made to appear next to a specific menu item; I have this
working fine. However, does there exist a similar mechanism to convince the
system to place small color icons next to items, such as it does for the
System 7 Apple menu and application switch menu?

Rich

- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer, Quickdraw Group
GCC Technologies

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

From: [e-mail] (Alexander M. Rosenberg)
Date: 8 May 92 20:15:41 GMT
Organization: Hackers Anonymous

In article <[e-mail]>, [e-mail] (Rich Siegel) writes:
>
> I know that by putting the appropriate value in the itemCmd field, a 'sicn'
> resource can be made to appear next to a specific menu item; I have this
> working fine. However, does there exist a similar mechanism to convince the
> system to place small color icons next to items, such as it does for the
> System 7 Apple menu and application switch menu?
>
> Rich

Yes. It isn't documented. It isn't likely to be. Unfortunately, it wasn't ever
designed as something that would be used outside of Apple.

- ---------------------------------------------------------------------------
- -  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
- -  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
- -  Palo Alto, CA 94301     -                                - Systems     -
- -  [phone]          - Nobody is my employer so       - :-)         -
- -  [phone]          - nobody cares what I say.       -             -

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

From: [e-mail] (Jon Pugh)
Date: 8 May 92 20:00:41 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Rich Siegel) writes:
>
> I know that by putting the appropriate value in the itemCmd field, a 'sicn'
> resource can be made to appear next to a specific menu item; I have this
> working fine. However, does there exist a similar mechanism to convince the
> system to place small color icons next to items, such as it does for the
> System 7 Apple menu and application switch menu?

The System MDEF uses cicn resources if they are present in favor of ICON
resources.  You can create small cicn resources since cicns are of variable
size.  Thus, do the same thing you would for an ICON but provide a small
cicn of the same id instead.

Of course, this only works on color systems and on b&w systems you get the
ICON resource, I think.  Come to think of it, I haven't used a 68000 in
quite some time.  Maybe I do need a PB 100 for testing...

Jon

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

From: [e-mail] (Bill Leue)
Subject: Tech Note or Other Apple Doc on MIDI
Date: 8 May 92 15:55:14 GMT
Organization: General Electric Research & Development

Was there ever a TechNote or otehr document from Apple about
MIDI?  I've looked through my TechNotes index but can't find
anything.

Thanks!

- -Bill Leue
[e-mail]

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

From: Jim Cook <[e-mail]>
Organization: Prime Computer, Inc.
Date: Fri, 8 May 1992 17:02:37 GMT

In article <[e-mail]> [e-mail] (Bill Leue)
writes:
>Was there ever a TechNote or otehr document from Apple about
>MIDI?  I've looked through my TechNotes index but can't find
>anything.
>
>Thanks!
>
>-Bill Leue
>[e-mail]
>
There is the Apple MIDI software and documentation available from ADPA.
Perhaps this is what you are thinking of.

J



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

From: [e-mail] (Ian Florance)
Subject: AppleEvents and TCL
Date: 5 May 92 01:21:01 GMT
Organization: Comp Sci, Uni of Adelaide, Australia

I am sending this on behalf of a friend but you can send followups as per
normal......


I am writing a DNA sequence analysis program to teach myself TCL/Macintosh
programming. I am having problems with AppleEvents; when my application
starts it displays an about box title screen, to update the screen while
doing this I call TCL's CApplication::Process1Event.
However this routine intercepts the 'oapp' AppleEvent and creates a new
document on top of my about box, so my about box has to intercept the
AppleEvents before the application does (no problem so far just add in a
DoAppleEvent method to the About box class). The problem is that I can dispose
of the Apple Event, but I want the about box to repost them, effectively just
deferrin the events so that the application does all the required events if it
is called on by another application etc. How do I keep track of the intercepted
events to re-broadcast them.
Also does anyone have a decent implimentation of general 3D graphic view system
(my sequence analysis program requires 3D graphics for some of it's functions).

Thanks... Daniel Kortschak ;-)


___________________________________________           _--_|\
Ian Florance         Phone : [phone]          /      \
The Univeristy of Adelaide Apple Consortium          \_.--*_/
University of Adelaide,     South Australia                v

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

From: [e-mail] (Jon W{tte)
Date: 6 May 92 18:58:45 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.edu.au> [e-mail] (Ian Florance) writes:

   I am writing a DNA sequence analysis program to teach myself TCL/Macintosh
   programming. I am having problems with AppleEvents; when my application
   starts it displays an about box title screen, to update the screen while
   doing this I call TCL's CApplication::Process1Event.
   However this routine intercepts the 'oapp' AppleEvent and creates a new
   document on top of my about box, so my about box has to intercept the


You could override CApplication::Process1Event in your own code to
not accept high-level events under certain conditions.

- --
h++ - new and improved !

"It's simple. Some people have braces in their names, and some don't. You'll
   just have to accept it the way it is." - Me: [e-mail]; Jon W{tte

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

From: [e-mail] (Jon Pugh)
Date: 8 May 92 19:56:58 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Ian Florance) writes:
>
> I am writing a DNA sequence analysis program to teach myself TCL/Macintosh
> programming. I am having problems with AppleEvents; when my application
> starts it displays an about box title screen, to update the screen while
> doing this I call TCL's CApplication::Process1Event.
> However this routine intercepts the 'oapp' AppleEvent and creates a new
> document on top of my about box, so my about box has to intercept the
> AppleEvents before the application does (no problem so far just add in a
> DoAppleEvent method to the About box class). The problem is that I can dispose
> of the Apple Event, but I want the about box to repost them, effectively just
> deferrin the events so that the application does all the required events if it
> is called on by another application etc. How do I keep track of the intercepted
> events to re-broadcast them.
> Also does anyone have a decent implimentation of general 3D graphic view system
> (my sequence analysis program requires 3D graphics for some of it's functions).

You are making this too difficult, although so is TCL since they made some
dopey use of the 'oapp' event.

Only put up a splash screen if the application is launched, not if a document
is opened. This more completely defines when your splash occurs.  This also
means you should only put your splash screen up as a _result_ of the oapp, so
you would avoid this problem completely.

To do this, you have to override CApplication::DoAppleEvent.

I personally believe that DoAppleEvent should call StartupAction and you
should override that, but I didn't write the damned thing. ;)

Jon

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

From: [e-mail] (Mike Hennahane)
Subject: Drag and Drop onto a document?
Date: 5 May 92 08:57:58 GMT
Organization: CS Department, Stanford University, California, USA


If the proper FREF resource is put into a document, will it be able to
handle apple events? I was wondering about this with regards to the
following idea:

I am using 4th Dimension, which can handle apple events when it is
running through the use of external code resources (essentially
XCMDs). I would like to be able to drop a TEXT file onto the structure
file icon of the currently open database, and have the data in the
TEXT file imported automatically.

Does this sound at all possible?

Another (silly) example of this idea: I have a document open in Word.
I drop a TEXT file onto the icon of the open document.  The TEXT file
is appended onto my open document (yes, magically, since Word has no
external code capability).

If possible, email me a copy of any followup article you post, since I
don't have the luxury of reading this forum often (except digested [ick]).

- --mike
[e-mail]

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

From: [e-mail] (Jeremiah Blatz)
Date: 7 May 92 23:23:53 GMT
Organization: Dartmouth College, Hanover, NH

System 7 provides no support for drag-and-drop onto documents :-(

Some ideas I have on this subject are:
   Make each doc a mini-app that will check to see if it got a
drag-and-drop and, if so, open its creator and do the needed stuff with
the document that was dropped onto it. If it didn't get an apple event
it could just open its creator app and transfer it's (the
mini-app/document's) data to the creator app. To minimize memory
useage, the mini-app/doc could be a so-called "faceless app."
   Write an init to allow drag-and-drop to certain documents.

Just a thought...
Jeremiah

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

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