Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-118

Text File | 1995-12-31 | 49.5 KB | 1,305 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 25 Oct 95       Volume 3 : Issue 118

Today's Topics:

        Accessing color table for PICT
        Apple Event: How to get Address of sender
        Calling a PPC trap not in InterfaceLib
        Custom Palettes with GWorld & Picts...
        Pixel data -> GWorld possible?
        Sound Timing Question
        What is the most current electronic reference?
        [Q] How to notify Finder of renamed files?
        how to identify cd volumes



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

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news 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].

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

>From [e-mail] (Melissa A. Hines)
Subject: Accessing color table for PICT
Date: Sat, 07 Oct 1995 08:31:17 -0500
Organization: Cornell University

The subject says it all:

How do I get a hold of the color table for a given PICT? I need to change
it within my program.

Thanks a bunch

Melissa
--
Melissa A. Hines                   [e-mail]
Dept. of Chemistry
Cornell University

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

>From [e-mail] (Chris De Salvo)
Date: Sun, 08 Oct 1995 00:02:26 -0700
Organization: MacPlay

In article <Melissa.Hines-0710950831170001@128.253.229.125>,
[e-mail] (Melissa A. Hines) wrote:

> The subject says it all:
>
> How do I get a hold of the color table for a given PICT? I need to change
> it within my program.

What you're interested in is the call GetPictInfo().  You pass it a
PicHandle, a PictInfo record, and some commands and it returns stuff to
you.

You can have it return you a PaletteHandle or a CTabHandle for the PICTs colors.

Here is a basic usage to get back a CTabHandle:

PictInfo    thePictInfo
PicHandle   thePict;
OSErr       theErr;
CTabHandle  myCLUT;

   //
   //  Load the data for "thePict" here
   //

   theErr = GetPictInfo(thePict, &thePictInfo, returnColorTable, 256
                        popularMethod, 0);

   if (! theErr)
      myCLUT = thePictInfo.theColorTable;

I'd suggest readng up on this call to see how all the arguments work.
There are three methods of sampling the colors:  systemMethod,
popularMethod, medianMethod.  You'd need to see which one is best for your
purposes.

L8R
Chris

--
+-----------------------------------------------------------------+
| [e-mail]         |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

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

>From [e-mail] (Michael C. Whidden)
Subject: Apple Event: How to get Address of sender
Date: 7 Oct 1995 17:48:58 GMT
Organization: Univ. of Florida CIS Dept.

I'm experimenting with remote apple events.  I have been trying to
figure out how to get the address of the App that sends me an event.

I tried getting it out of the keyAddressAttr of the reply Event, but
it gives me an error about an unknown address type (-1716) when I
use AESend to that target address.

I thought about somehow writing my server to send the client its own
addressdesc, but I have know idea how to find out what it is.

I know the Idle Proc when waiting for a reply gives you the addressdesc
of the sender, but I don't want to write a idle proc.

Anybody have any ideas?

Thanks,
Mike

--
    /\   /|                                  |  [e-mail]
    | \ | |      \                           |  [e-mail]
   /  | | |  @   |  /                        |  [e-mail]
  /    \| |  \   |/      ___                 |And don't miss all the great

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

>From [e-mail] (Jon Pugh)
Date: Mon, 9 Oct 1995 20:14:29 GMT
Organization: Will hack for food

Michael C. Whidden ([e-mail]) wrote:
> I'm experimenting with remote apple events.  I have been trying to
> figure out how to get the address of the App that sends me an event.

> I thought about somehow writing my server to send the client its own
> addressdesc, but I have know idea how to find out what it is.

I would include a TargetID in the Apple event.  It's a specification
of the machine, zone and port name.  It's pretty simple to create too.
Using that, you can easily create an address desc to use.

Jon


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

>From [e-mail] (Ethan Funk)
Date: Mon, 09 Oct 1995 17:45:14 -0400
Organization: ServiceTech, Inc.

Michael C. Whidden ([e-mail]) wrote:
> I'm experimenting with remote apple events.  I have been trying to
> figure out how to get the address of the App that sends me an event.

> I thought about somehow writing my server to send the client its own
> addressdesc, but I have know idea how to find out what it is.

Wow... For once I get to answer a question instead of ask! (Sorry, this is
just very exciting for me.)

Here is what I did for a program I am writing that accepts apple events
from a 'client'.  The client first sends a login apple event.  When my
program receives this event, it extracts the address of the sender from
the apple event and adds it to a list of addresses that it echos all other
outgoing event to.  (It sounds weird, but it does the job for my
application.

Here is the code (in C) for the procedure that handles the reception of
the login event:

pascal OSErr DoAppLogIn(AppleEvent theAppleEvent, AppleEvent reply, long refCon)
{
   struct AddressList   *AddressPtr, *NewRec;
   OSErr                err;
   AppleEvent           temp;

// AppList is a global variable pointing to the list
// "struct AddressList" is my structure for the address list records

   AddressPtr = AppList;

// finds the last entry in the list

   while(AddressPtr->nextRec)
      AddressPtr = AddressPtr->nextRec;

// Create a new record to store the extracted address in my list

   if(NewRec = (struct  AddressList *)NewPtr(sizeof(struct AddressList))){

//  This is where I extract the address of the sender

      err = AEGetAttributeDesc(&reply, keyAddressAttr, typeWildCard,
                                                          &(NewRec->address));

// This is where I store the extracted address in the new record and link
it to // the end of the list.  Note: clientID is an ID number I send back
to the
// client for a reference it be used in future transactions.

     if(err == noErr){
         AddressPtr->nextRec = NewRec;
         NewRec->clientID = AddressPtr->clientID + 1;
         NewRec->prevRec = AddressPtr;
         NewRec->nextRec = nil;

         err = AEPutParamPtr(&reply, 'clID', 'long', &NewRec->clientID,
                                                                sizeof(long));
//  I send the client his clientID

         if(err == noErr)
            err = AESend(&reply, &temp, kAENoReply + kAECanInteract,
                                              kAENormalPriority, 0, nil, nil);
         AEDisposeDesc(&temp);
         AEDisposeDesc(&reply);
         SendLists(&(NewRec->address));
      }
      else{
         AEDisposeDesc(&(NewRec->address));
         DisposePtr((void *)NewRec);
      }
   }
}

// The end!

I hope this helps.

Ethan...

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

>From "Andrew C. Plotkin" <[e-mail]>
Subject: Calling a PPC trap not in InterfaceLib
Date: Wed,  4 Oct 1995 16:48:13 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

I have spent three and a half hours trying to figure out how to move
the cursor around the screen. (YES, I tried to convince my boss it
shouldn't be done. I lost.)

This took an unbelievable amount of time. (Remember the first time you
tried to find out how to implement TrapAvailable? That was 45 minutes
by itself. I think I found it in a QuickTime tech note.) But that's
not my question.

My question is, how do I link in the Cursor Device Manager calls? I'm
#including <CursorDevices.h>, which defines inline assembly in 68K
code, but when I try to compile the PPC version I get link errors --
it can't find the functions.

This is under CodeWarrior 5.

My copy of NIM:PPC System Software is at home; Apple's web site won't
give me its Acrobat version (even *after* I spend twenty minutes
installing Acrobat off my develop 23 CD, which didn't have any useful
information either); Metrowerks's web site doesn't seem to say how to
do it... Oh, and I have to turn something in today, and if I'm home
later than 8 I'll miss the DS9 premiere -- I mean, uh...

I *am* frustrated here. (Star Trek aside.)

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

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

>From [e-mail] (Colen Garoutte-Carson)
Date: 5 Oct 1995 21:22:39 GMT
Organization: Metrowerks Inc.

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> My question is, how do I link in the Cursor Device Manager calls? I'm
> #including <CursorDevices.h>, which defines inline assembly in 68K
> code, but when I try to compile the PPC version I get link errors --
> it can't find the functions.

Andrew,

     My CursorDevices.h contains the following warning :

/*
                      * * *  W A R N I N G  * * *

   On currently shipping PowerMacs, the CursorDevices manager is implemented
   in 68K code and emulated.  Unfortunately, the MixedMode glue in InterfaceLib
   is incorrect.  It and the 1.0 version of this file had incorrect parameter
   lists for most functions.

   As a first step to avoid runtime errors, the functions in this file were
   renamed (e.g. from"CrsrDevButtons" to "CursorDeviceButtons").  This
will result
   in a link time error if a PowerPC application tries to call the functions.
   When InterfaceLib is fixed, the new names will be exported and PowerPC
   code will then be able to call them.

*/

     I believe this means that Apple is aware of the problem, as has yet
to fix it...
     What you could do is; create a 68K routine that calls the
CursorDevices.h routine you want.  Disassemble that routine, and save the
68K hex code.  At runtime, in your PPC program, allocate a pointer and
store the 68K hex code in it.  Use CallUniversalProc to jump to the data.
Since it's 68K code, it should not require a routine descriptor.  There
are probably other purmutations of this approach that would work.  And,
since the CursorDevices manager is implemented in 68K code and emulated,
you should not lose any speed.

 - Colen Garoutte-Carson, Metrowerks Inc.

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

>From [e-mail] (Ari Halberstadt)
Date: Fri, 06 Oct 1995 08:11:47 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

>I have spent three and a half hours trying to figure out how to move
>the cursor around the screen. (YES, I tried to convince my boss it
>shouldn't be done. I lost.)

Ahem, Andy, most of us just push the mouse around. When we do, our bosses
smile because they think we're working. :-)

>
>This took an unbelievable amount of time. (Remember the first time you
>tried to find out how to implement TrapAvailable? That was 45 minutes
>by itself. I think I found it in a QuickTime tech note.) But that's
>not my question.
>
>My question is, how do I link in the Cursor Device Manager calls? I'm
>#including <CursorDevices.h>, which defines inline assembly in 68K
>code, but when I try to compile the PPC version I get link errors --
>it can't find the functions.

I don't know squat about the CDM, but assume that there is no PPC glue in
existence. You need to compile the routines as 68K code with Mixed Mode
muck around them. I *think* something like the following tortuous mess
will do.

Use a selector-based switch statement accessed via
GlueSomeAppleFooWithASwitch with a union being used to pass parameters in
a single block which is then broken back into individual params. Something
hideous like

int SomeAppleFoo(foo, stuff) = { 0x1234, 0x5678 }; // a CDM thing

void GlueSomeAppleFooWithASwitch(AppleFooGlueSelector selector,
AppleFooGlueParamBlock *params)
{
   switch (selector) {
   case kSomeAppleFoo:
       params->SomeAppleFoo.result =
SomeAppleFoo(params->SomeAppleFoo.foo, params->SomeAppleFoo.stuff);
      break;
   case kSomeOtherAppleFoo:
      SomeOtherAppleFoo(params->SomeOtherAppleFoo.foo,
params->SomeOtherAppleFoo.foo);
      break;
   default:
      DebugStr("\pThis Foo does not belong in Cupertino.");
   }
}

Compile the above as 68K code and stick it in a resource of some arbitrary
type.  Then, to call it, use something even more hideous:

int PPCSomeAppleFoo(foo, stuff)
{
   AppleFooGlueParamBlock params;

  glueH = GetResource('GAPF', rGlueAppleFoo);
  glueState = HGetState(glueH);
  HLock(glueH);
  entryPoint = (GlueSomeAppleFooWithASwitchPtr) *glueH;
  params.SomeAppleFoo.foo = foo;
  params.SomeAppleFoo.stuff = stuff;
  CallUniversalProc(entryPoint, GlueSomeAppleFooWithASwitchProcInfo,
    kSomeAppleFoo, ¶ms);
  HSetState(glueH,glueState);
  return params.SomeAppleFoo.result;
}

You need to invent a procInfo thing for GlueSomeAppleFooWithASwitch, using
the magic constants in MixedMode.h.

I think the Component Manager might handle some of this muck for you.

The above solution is so ugly, there must be a better way.

>do it... Oh, and I have to turn something in today, and if I'm home
>later than 8 I'll miss the DS9 premiere -- I mean, uh...

Hey, we have to wait till Saturday! No spoilers, please.

-- Ari Halberstadt ([e-mail], [e-mail])
For latest versions of some of my Macintosh software try <ftp://ftp.shore.net/members/ari>.

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

>From [e-mail] (Brian Stern)
Date: 6 Oct 1995 13:14:52 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

<I have spent three and a half hours trying to figure out how to move
<the cursor around the screen. (YES, I tried to convince my boss it
<shouldn't be done. I lost.)
<
<This took an unbelievable amount of time. (Remember the first time you
<tried to find out how to implement TrapAvailable? That was 45 minutes
<by itself. I think I found it in a QuickTime tech note.) But that's
<not my question.
<
<My question is, how do I link in the Cursor Device Manager calls? I'm
<#including <CursorDevices.h>, which defines inline assembly in 68K
<code, but when I try to compile the PPC version I get link errors --
<it can't find the functions.
<
<This is under CodeWarrior 5.
<
<My copy of NIM:PPC System Software is at home; Apple's web site won't
<give me its Acrobat version (even *after* I spend twenty minutes
<installing Acrobat off my develop 23 CD, which didn't have any useful
<information either); Metrowerks's web site doesn't seem to say how to
<do it... Oh, and I have to turn something in today, and if I'm home
<later than 8 I'll miss the DS9 premiere -- I mean, uh...
<
<I *am* frustrated here. (Star Trek aside.)
<
<--Z
<
<"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

I don't know anything about the cursor control manager but you can call
68K code using CallUniversalProc.  There is an example on the CD called
SwitchBank that shows how to call the ServerDispatch trap in this way.

The basic strategy is to build a static array that holds the 68K opcodes
(with an rts at the end).  Build the appropriate procinfo.  Pass
CallUniversalProc the address of the static array and the procinfo and
you're all set.  This should all go in a header file with appropriate
ifdefs so that it works the same in 68K code as in PPC code.

It's a bit goofy but it works.

____________________________________________________________________
Brian  Stern  {;-{)}                  Toolbox commando and Menu bard                  [e-mail]                          [e-mail]
INIT Writing FAQ etc. at <ftp://ftp.pbcomputing.com//Guests/BrianS/>

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

>From "Andrew C. Plotkin" <[e-mail]>
Date: Fri,  6 Oct 1995 11:36:22 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

Various people have given me various workable answers. Thanks all. The
nicest one actually mailed me a newer copy of InterfaceLib, so I
should be able to get something to work.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

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

>From [e-mail] (Mark W. Allender)
Date: 10 Oct 1995 16:38:08 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Colen Garoutte-Carson ([e-mail]) wrote:
: /*
:                       * * *  W A R N I N G  * * *

:    On currently shipping PowerMacs, the CursorDevices manager is implemented
:    in 68K code and emulated.  Unfortunately, the MixedMode glue in InterfaceLib
:    is incorrect.  It and the 1.0 version of this file had incorrect parameter
:    lists for most functions.
:
:    As a first step to avoid runtime errors, the functions in this file were
:    renamed (e.g. from"CrsrDevButtons" to "CursorDeviceButtons").  This
: will result
:    in a link time error if a PowerPC application tries to call the functions.
:    When InterfaceLib is fixed, the new names will be exported and PowerPC
:    code will then be able to call them.
:
: */

InterfaceLib that shipped with CW6 (and some version of MPW that I can't track
down right now) had the new routine names defined.  Thery werer subsequently
gome in CW7 (due to a problem with apple I heard....).  I've been using
CDM calls in my application without any link error (assuming that I use the
appropriate interfaceLib).

--
-Mark Allender
-Parallax Software
[e-mail]

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

>From [e-mail] (Jeremy Moskovich)
Subject: Custom Palettes with GWorld & Picts...
Date: Sun, 08 Oct 1995 00:01:44 +0200
Organization: (none)

hi,
    I'm trying to set up a custom color palette for an image I want to display.
  Heres what I've arrived at so far:
a)Create a GWorld
b)Create a new palette with NewPalette() derived from 'clut' id. 8, with
256 entries, pmTollerant, & the tollerance set to 0x0000.
c)Add all the colors I want to the new palette with SetEntryColor().
d)Assign the palette to the Gworld with NSetPalette().
e)Do some drawing in the GWorld.
f)Create a new Cwindow.
g)Assign the same palette to the CWindow (again with NSetPalette()).
h)set the ctSeed of the Window and the GWorld to equal one another.
i)Copybits the image from the Gworld to the CWindow.

   Is this correct?  Am I missing some fundamental step?

   On a different note, does anyone know how to create a PICT with a
custom color table?  Is the current color table automatically used when I
call OpenCPicture()?

Thanks in advance,
Jeremy
P.S. Please CC me any replies to this post if possible since my news
server isn't very reliable.

*-=-=-=-=-=-=-=-=-=-= Jeremy Moskovich | [e-mail] =-=-=-=-=-=-=-=-*
+ -=-=-=-   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   -=-=-=- +
|        If it moves eat it, if it doesn’t move eat it anyway! - pacman        |
|     Penn&Teller, The PRODIGY, SoundGarden, RC, C, 1984, Baking, StarTrek     |
*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*

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

>From [e-mail] (Tim Dierks)
Date: Sat, 07 Oct 1995 18:56:02 -0700
Organization: Best Internet Communications

In article <[e-mail]>, [e-mail] (Jeremy Moskovich) wrote:
>    I'm trying to set up a custom color palette for an image I want to display.
>  Heres what I've arrived at so far:
>a)Create a GWorld
>b)Create a new palette with NewPalette() derived from 'clut' id. 8, with
>256 entries, pmTollerant, & the tollerance set to 0x0000.
> [ c-i omitted ]

The Palette Manager doesn't work (or at least, not very well), with
GWorlds. What you want to do is make sure you GWorld has the right colors, your
window has the right colors, and then let CopyBits do the work of converting
between the actual indices. Thus, set up a clut handle and pass it to
NewGWorld. This will ensure you've got the right colors available
off-screen. Make your clut into a palette and apply it to your window. This
will ensure you've got the right colors on-screen. CopyBits away.

If you're looking for the speed of having the color tables match, index for
index, you need to do the palette first, make sure your window is active, then
steal the clut from the GDevice you wish to match (which is probably the one
which matches the offscreen in depth, etc., and which most of the window in
question is on) and use it when creating the GWorld. Alternately, just use the
noNewDevice flag and pass the global rectangle of your window. However, if
ultra-speed isn't needed, the first method is preferred (it's cleaner).

>   On a different note, does anyone know how to create a PICT with a
>custom color table?  Is the current color table automatically used when I
>call OpenCPicture()?

No; when you do a CopyBits(), the color table of the source is stored with the
pixels. This will be used when playing the picture back. Thus, if you've got an
offscreen, SetGWorld() to it, OpenCPicture() then CopyBits() the image on top
of itself; ClosePicture() and voila! Serves 4.

 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

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

>From [e-mail] (Jeremy Moskovich)
Date: Mon, 09 Oct 1995 02:15:26 +0200
Organization: (none)

>What you want to do is make sure you GWorld has the right colors, your window
>has the right colors, and then let CopyBits do the work of converting between
>the actual indices. Thus, set up a clut handle and pass it to NewGWorld. This
>will ensure you've got the right colors available off-screen. Make your clut
>into a palette and apply it to your window. This will ensure you've got the
>right colors on-screen. CopyBits away.

    How do I set individual entries in a color table?  Apart from the
ctSize field, think ref. doesn't say much about what the fields in a
ColorTable do...
    Can I just create a new palette, set up the entries with
SetEntryColor() and then call Palette2CTab() to get my ColorTable to apply
in NewGWorld()?

>If you're looking for the speed of having the color tables match, index for
>index, you need to do the palette first, make sure your window is active, then
>steal the clut from the GDevice you wish to match (which is probably the one
>which matches the offscreen in depth, etc., and which most of the window in
you mean doing something like?:
    SetGWorld( CWind, targetGDHand );
    Err = NewGWorld( MyGWorldPtr, 8, Cwind->port.portRect,
                     Cwind->port.(**(portPixMap)).pmTable, //the Window's CLUT?
                     0,0);

>question is on) and use it when creating the GWorld. Alternately, just use the
>noNewDevice flag and pass the global rectangle of your window. However, if

you mean?:
   GlobalRect = MyRectLocal2Global( Cwind->port.portRect );
   Err = NewGWorld( MyGWorldPtr, 8, GlobalRect, 0, 0, noNewDevice );

Thanks!,
Jeremy

*-=-=-=-=-=-=-=-=-=-= Jeremy Moskovich | [e-mail] =-=-=-=-=-=-=-=-*
+ -=-=-=-   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   -=-=-=- +
|        If it moves eat it, if it doesn’t move eat it anyway! - pacman        |
|     Penn&Teller, The PRODIGY, SoundGarden, RC, C, 1984, Baking, StarTrek     |
*-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*

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

>From [e-mail] (Andrew Southwick)
Date: 10 Oct 1995 18:59:00 GMT
Organization: IBM SWSD, Performance Tools, LEX

[e-mail] (Jeremy Moskovich) writes:
>    I'm trying to set up a custom color palette for an image I want to display.
>  Heres what I've arrived at so far:

Rearrange the order you do things in this way:
 a) create a 'clut' resource with all of the entries you want using ResEdit
 b) load in the 'clut' into memory
 c) change entries in the clut if you want to
 d) Create a GWorld, and specify this color table as the one you want to use
 e) draw in the GWorld
 f) create a CWindow
 g) convert the clut into a palette
 h) NSetPalette( myCWindow, myNewPalette )
 i) do the ctSeed slam
 j) CopyBits

>   On a different note, does anyone know how to create a PICT with a
>custom color table?  Is the current color table automatically used when I
>call OpenCPicture()?

A color table is saved with a PICT resource.  A new color table will be
created when you close the picture, containing an entry for each different
RGB color you drew with while the picture was open.  If you are drawing to
the screen, then only entries in the color table used by that monitor will
be used (although, if you use only a subset of all of the entries in that
color table, only those *actually used* will be in the color table saved
with the PICT).  Likewise for GWorlds.  Whatever it looks like on the screen,
the PICT will save the exact RGB colors.

>*-=-=-=-=-=-=-=-=-=-= Jeremy Moskovich | [e-mail] =-=-=-=-=-=-=-=-*


Andrew R Southwick          -={C++/OO Programmer}=-     [e-mail]
#include "disclaimer.std"                                  I speak not for IBM.
            -= Freedom by permission is a contradiction in terms =-


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

>From [e-mail]
Subject: Pixel data -> GWorld possible?
Date: Thu,  5 Oct 95 19:11:07 +500
Organization: IDS World Network Internet Access Service, (800)IDS-1680

Hello all.

I have written a program the reads a raw image data file into memory and
displays it in a window on the screen by way of multiple calls to
SetCPixel(). To avoid the "scanning display" effect that occurs when an image
is drawn one pixel at a time (I find it appealing, but my customer does not),
I am drawing into an offscreen GWorld and then CopyBits()ing the resultant
image onto the screen.

However this method seems a bit redundant: the data is already in memory, so
why shouldn't I be able to just BlockMove() it into the GWorld's pixMap
instead of doing it pixel by pixel? I tried doing just this, using
BlockMove() to transfer the pixel data from the image's pointer to the
baseAddr of the GWorld's pixMap. Apparently I didn't know what I was doing,
because I was confronted with a nasty bus error. Still it seems like this
_should be_ possible somehow.

Anyone know the solution? Any help would be greatly appreciated! Thanks!
--
Louis Deaett      | "It's not how powerful the computer is, it's how
<[e-mail]> | much more powerful it is than those of your peers."

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

>From [e-mail] (Ed Anson)
Date: Fri, 06 Oct 1995 00:19:20 -0400
Organization: Tulip Software

In article <451oob$[e-mail]>, [e-mail] wrote:

> I have written a program the reads a raw image data file into memory and
> displays it in a window on the screen by way of multiple calls to
> SetCPixel(). To avoid the "scanning display" effect that occurs when an image
> is drawn one pixel at a time (I find it appealing, but my customer does not),
> I am drawing into an offscreen GWorld and then CopyBits()ing the resultant
> image onto the screen.
>
> However this method seems a bit redundant: the data is already in memory, so
> why shouldn't I be able to just BlockMove() it into the GWorld's pixMap
> instead of doing it pixel by pixel? I tried doing just this, using
> BlockMove() to transfer the pixel data from the image's pointer to the
> baseAddr of the GWorld's pixMap. Apparently I didn't know what I was doing,
> because I was confronted with a nasty bus error. Still it seems like this
> _should be_ possible somehow.

Since you already have the pixel data in memory, the GWorld is indeed
redundant. Generally, it is useful for creating offscreen pixmaps.

You can create your own PixMap and set it up to reference the pixel
buffer. Then you just blast it to the screen with CopyBits. The info in
Inside Mac is sufficient to guide you through the process. I also wouldn't
be surprised if there is half a ton of sample code on the Developer CD.

As for your bus error: I'm not really sure what happened to you. However,
it's not considered cool to write directly to the GWorld buffer. In some
implementations, it doesn't really exist in your address space. Although
you can force it to be in accessible memory, that's another subject and
you don't need to worry about that today.

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

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

>From [e-mail] (Mike DiChiappari)
Date: Mon, 09 Oct 1995 22:18:34 -0500
Organization: The Internet Access Company

In article <451oob$[e-mail]>, [e-mail] wrote:

> I have written a program the reads a raw image data file into memory and
> displays it in a window on the screen by way of multiple calls to
> SetCPixel(). To avoid the "scanning display" effect that occurs when an image
> is drawn one pixel at a time (I find it appealing, but my customer does not),
> I am drawing into an offscreen GWorld and then CopyBits()ing the resultant
> image onto the screen.
>
> However this method seems a bit redundant: the data is already in memory, so
> why shouldn't I be able to just BlockMove() it into the GWorld's pixMap
> instead of doing it pixel by pixel? I tried doing just this, using
> BlockMove() to transfer the pixel data from the image's pointer to the
> baseAddr of the GWorld's pixMap. Apparently I didn't know what I was doing,
> because I was confronted with a nasty bus error. Still it seems like this
> _should be_ possible somehow.

Louis,

First, you don't need the memory buffer.  Just read the image file into
the offscreen GWorld.  You must place the data in the offscreen GWorld's
PixMap in the correct format (32 bit, 16 bit, etc…).  You need to do the
following:

1) Create an offscreen NewGWorld() of the appropriate pixel depth and
size.  If you are using color lookup tables, then you will have to set one
of these up too.

2) Lock that new GWorld PixMap's baseAddr.  The baseAddr is the start of
the image data and it must be locked, because it may be a handle.  To lock
it use LockPixels().  NOTE: This is probably why your call to BlockMove()
failed.

3) After you lock the pixels you can get the baseAddr by calling
GetPixBaseAddress().

4) Before accessing the baseAddr you may want to call SwapMMUMode() if you
want you application to work when 32 bit addressing isn't turned on.

5) Now you can write the the PixMap's baseAddr.  Don't go past the end of
it, though.  Make sure you format the data properly given the PixMap's
pixelType, pixelSize, cmpCount, and cmpSize.  In other words, format the
image data appropriately.

6) When you are finished, call UnlockPixels().

Mike

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

>From Jefferson Provost <[e-mail]>
Subject: Sound Timing Question
Date: Mon,  9 Oct 1995 14:28:48 -0400
Organization: Psychology, Carnegie Mellon, Pittsburgh, PA


Hi,

I have an application which I need to play sampled sounds with very
tight control over the timing.  In particular, I need:

a) The Sound Manager to play a sound as quickly as possible after the
application asks for it to be played

b) To know as closely as possible when a sound actually started playing.


I had hacked up a method which worked fairly well before Sound Manager
3.0, but that I've just discovered doesn't work well at all with SM 3.0
or later.

What I do is create a SndDoubleBufferHeader struct that points to two
buffers.  The first buffer is empty, and has 0 samples.  The second
buffer contains the sound I want to play.  Then when I call
SndPlayDoubleBuffer, my DoubleBackProc is called immediately, at which
point I save the time and call it the starting time of the sound.

This worked fine before SM 3.0.  I tested it by hooking up the speaker
out to an external voice key, which then ran back to my app via the
serial port.  Using this method I could see that the sound was
_actually_ starting around 2ms after my DoubleBackProc was being called.

Now, however, with SM 3.0 (or 3.1), it can take anywhere from 50 to 100
msec for my sound to start _after_ my DoubleBackProc is called.  (50ms
on a IIci, and anywhere from 60 to 100ms on a 7100/66 running emulated
code with speed doubler)

What's taking it so long?  And does anyone know what I can do to fix it?
 I find it kind of ironic that the Tech Notes and Develop article on the
changes for SM 3.0 brag about how much faster and more efficient SM 3.0
is, yet in the one area in which I need to it be efficient, it's
actually much slower.

Any help, anyone?

J.



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

>From Hubert Voogd <[e-mail]>
Date: 10 Oct 1995 11:03:51 GMT
Organization: E.R.G. department of Psychology, KU Nijmegen

Jefferson Provost <[e-mail]> wrote:
>
>Hi,
>
>I have an application which I need to play sampled sounds with very
>tight control over the timing.  In particular, I need:
>
>a) The Sound Manager to play a sound as quickly as possible after the
>application asks for it to be played
>
>b) To know as closely as possible when a sound actually started playing.
>
[Hacked method snipped..]
>
>This worked fine before SM 3.0.  I tested it by hooking up the speaker
>out to an external voice key, which then ran back to my app via the
>serial port.  Using this method I could see that the sound was
>_actually_ starting around 2ms after my DoubleBackProc was being called.

Yep, but this is a solution to b), it still has the problems to a)

>
>Now, however, with SM 3.0 (or 3.1), it can take anywhere from 50 to 100
>msec for my sound to start _after_ my DoubleBackProc is called.  (50ms
>on a IIci, and anywhere from 60 to 100ms on a 7100/66 running emulated
>code with speed doubler)
>
>What's taking it so long?  And does anyone know what I can do to fix it?
> I find it kind of ironic that the Tech Notes and Develop article on the
>changes for SM 3.0 brag about how much faster and more efficient SM 3.0
>is, yet in the one area in which I need to it be efficient, it's
>actually much slower.

Nope, you are fooled. The DoubleBackProc _had_ a delay, but now, it
doesn't have that delay anymore. Look at the delay of the DoubleBackProc
in older SoundManagers.

>Any help, anyone?
>
>J.

As a developer of C_Frame, I discovered this problem about 4 months ago,
by using a scope to look at the sound, triggering at the moment I wanted
a sound to play.
MacIntosh seems to put sound samples in the video buffer (much like
the Amiga uses a Copper list). Every 4th vertical blank, a sound can
appear from the speakers (causing a delay of max 4*17 ms). You have to
synchronise to that vertical blank.
Your DoubleBackProc had a delay before SoundManager 3.0 which was more
or less the equal to the delay the sound had. This way, you had a
solution to b). In SoundManager 3.0, the DoubleBackProc is called
without a delay, thus disabling the solution to b). There is no solution
to a), but to my experimentors, it is not important to control the
moment a sound is playing. It is more important to know that moment.
  I solved the problem in two different ways: 1) using a soundkey, to
measure the moment the sound starts playing. 2) Correcting data by
predicting that moment. The problem in 2) is that you have to know
the moment the first sound appears from the speakers, but you can
make a lot of guesses and then choose the correct guess.

If you need more information, e-mail me, or look at the C_Frame site:
http://kunpwe.psych.kun.nl/~voogd/C_Frame.html

Greetings, Hubert





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

>From [e-mail] (Duncan Widman)
Subject: What is the most current electronic reference?
Date: 5 Oct 1995 12:59:56 GMT
Organization: Drexel University, Philadelphia

I was wondering what is the most recent electronic reference for mac
toolbox calls. I have been using Think Ref, which I like a lot and
consider invaluable, but is version 2.01 and copyright 1992, so it only
contains IM up to the old vol IV. This is fine so far, but if I ever need
more up-to-date info, does Symantic have an upgrade plan, or is apple's
CD-rom version of IM better (not that I even have a CD-rom drive), or
does someone else (CodeWarrior?) make a better reference?

thanks bunches,
Duncan

--
______________________________________________________________________________
Duncan Widman  EE Class of 96
Drexel University
[e-mail]

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

>From [e-mail] (Paul J. Voogt)
Date: Fri, 06 Oct 1995 18:36:08 +0100
Organization: Euronet

In article <450ksc$[e-mail]>,
[e-mail] (Duncan Widman) wrote:

>I was wondering what is the most recent electronic reference for mac
>toolbox calls. I have been using Think Ref, which I like a lot and
>consider invaluable, but is version 2.01 and copyright 1992, so it only
>contains IM up to the old vol IV. This is fine so far, but if I ever need
>more up-to-date info, does Symantic have an upgrade plan, or is apple's
>CD-rom version of IM better (not that I even have a CD-rom drive), or
>does someone else (CodeWarrior?) make a better reference?

The latest version of Think Reference is 2.0.3 (although the databases
haven't been updated since 1992, Symantec did, however, include a new
database about TCL 2.0 in their latest release of C++ for Macintosh).
Symantec has no plans to update the product to the New Inside Macintosh
series.

There is an new electronic reference that is supported by Apple (they post
new databases regularly on their FTP sites). I's called "Macintosh
Programmer's Toolbox Assistant" and is published by Addison-Wesley on
CD-ROM (ISBN 0-210-96642-5) and costs about U$ 99,-. Although both are
hypertext-based I preferred the Think Ref interface over MPTA, but at least
MPTA is up to date and kept that way by Apple. BTW, Apple's CD-ROM version
of IM is very much worth while, and contains the same information as the
MPTA CD-ROM, but in a different format (DocViewer documents vs QuickView
databases). I guess you'll have to buy a CD-ROM...



--
Paul J. Voogt                                                  <[e-mail]>
- ----------------------------------------------------

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

>From [e-mail] (emb121 (Eric Bennett))
Date: 6 Oct 1995 23:37:43 GMT
Organization: Penn State University, Center for Academic Computing

In article <[e-mail]>
[e-mail] (Paul J. Voogt) writes:

> BTW, Apple's CD-ROM version
> of IM is very much worth while, and contains the same information as the
> MPTA CD-ROM, but in a different format (DocViewer documents vs QuickView
> databases). I guess you'll have to buy a CD-ROM...

Just remember that if you have the storage space, you can get most of
the core Inside Mac volumes from ftp.support.apple.com (the files are
in Adobe Acrobat PDF format).

-Eric Bennett ([e-mail])

Drawing on my fine command of the language, I said nothing.
-Robert Benchley

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

>From [e-mail] (Jordan Zimmerman)
Date: Fri, 06 Oct 1995 16:56:54 -0800
Organization: Altura Software, Inc.

> I was wondering what is the most recent electronic reference for mac
> toolbox calls. I have been using Think Ref, which I like a lot and
> consider invaluable, but is version 2.01 and copyright 1992, so it only
> contains IM up to the old vol IV. This is fine so far, but if I ever need
> more up-to-date info, does Symantic have an upgrade plan, or is apple's
> CD-rom version of IM better (not that I even have a CD-rom drive), or
> does someone else (CodeWarrior?) make a better reference?

The most current online reference would be Apple's Macintosh Programmer's
Toolbox Assistant (MPTA). Check out:
     http://www.info.apple.com/dev/MPTA.html

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Coming to you fast as lightning on a 9500/120!

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

>From [e-mail] (emb121 (Eric Bennett))
Date: 9 Oct 1995 18:17:49 GMT
Organization: Penn State University, Center for Academic Computing

In article <454ek7$[e-mail]>
[e-mail] (emb121 (Eric Bennett)) writes:

> Just remember that if you have the storage space, you can get most of
> the core Inside Mac volumes from ftp.support.apple.com (the files are
> in Adobe Acrobat PDF format).

Oops... that should be ftp.info.apple.com, specifically:

ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Technical
_Documentation/Inside_Macintosh/

Somebody emailed be about whether the files are on ftp.support--which
they're not--but the return address was not valid :(

-Eric Bennett ([e-mail])

Drawing on my fine command of the language, I said nothing.
-Robert Benchley

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

>From [e-mail] (Jason Townsend)
Subject: [Q] How to notify Finder of renamed files?
Date: Mon, 09 Oct 1995 14:25:47 -0500
Organization: University of Texas at Austin

I am working on a CodeWarrior C program called Guillotine that renames
files in batches with FSpRename (currently makes them all lowercase or all
uppercase using Text Utilities). I notify the Finder of the change by
changing the modification date of the enclosing folder so the user must
close and reopen the window to see the change. It is based on DropShell
2.0, so it uses the DropShell ForceFinderUpdate routine. It requires
System 7 or later.

I should be able to make the change visible without user intervention. Any
ideas on how I can do that?

Any help would be greatly appreciated.

-Jason

- ------------  <http://www.ece.utexas.edu/~townsend/>  -------------
"Whoa, Macs are cool."       |          [e-mail]
          -Me                | LC 575 20/540, MacOS 7.5.1, QDGX 1.1.2
- -  I believe in emailing courtesy copies of followup articles.  ---

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

>From [e-mail] (Erichsen)
Date: Mon, 09 Oct 1995 14:47:34 -0700
Organization: Disorganized

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

>I am working on a CodeWarrior C program called Guillotine that renames
>files in batches with FSpRename (currently makes them all lowercase or all
>uppercase using Text Utilities). I notify the Finder of the change by
>changing the modification date of the enclosing folder so the user must
>close and reopen the window to see the change. It is based on DropShell
>2.0, so it uses the DropShell ForceFinderUpdate routine. It requires
>System 7 or later.
>I should be able to make the change visible without user intervention. Any
>ideas on how I can do that?

I had the same problem with Drop•Rename (my application which does exactly
what you want but, suffers the same problem you're getting). It seems the
Finder takes a long time to update items that only have a case change
(changing the name in other ways will update immediately after bumping the
date).

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

>From [e-mail] (Ed Samuels)
Date: 9 Oct 1995 22:41:40 -0400
Organization: The Pipeline

In article <[e-mail]>, Jason
Townsend writes:

>I should be able to make the change visible without user intervention. Any

>ideas on how I can do that?

You have to send the Finder an "update container items" Apple Event--I
forget what the 4-letter code is at the moment, but you can easily check it
by looking at the "aevt"s in a copy of your Finder with Resorcerer. You'll
need to pass the Finder a list of aliases to the folders that you want to
update.

For some good Apple Event sample code which, although it does not discuss
the Update Items event in particular, provides a strong background for
sending almost any Apple Events to the Finder, I recommend the book
"Ultimate Mac Programming" by Dave Mark et al. The Apple ftp site is also
bound to have some good examples dealing with the subject.

By the way--you and your users will have to have either System 7.5, or 7.1
with the Finder Scripting Extension installed for this to work.

:)
___________________________________
Richard Samuels
[e-mail]

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

>From [e-mail] (john elemans)
Subject: how to identify cd volumes
Date: 9 Oct 1995 21:12:52 GMT
Organization: hundred peaches inc

Is there a way to walk the volume list and identify those volumes which are
CDs? TIA.
je

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

>From [e-mail] (Brian Bechtel)
Date: Mon, 09 Oct 1995 17:22:48 -0700
Organization: Apple Computer, Inc.

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

> Is there a way to walk the volume list and identify those volumes which are
> CDs?

Unfortunately, there is no good way to determine a CD-ROM drive on a
Macintosh. Just about every time you think you've come up with a good
method for detecting CD-ROM drives, some engineer comes up with a way to
defeat your check (without even knowing that they were accomplishing this
feat.)

As an example, here are some of the approaches you can take.

1) Look at the drive queue element for a mounted drive and see which
driver is pointed to by the dQRefNum.  Look at the driver name.  If it's
".AppleCD" then it's probably a CD-ROM drive.

This fails for non-Apple CD-ROM drives which have different driver names.

2) Look at the attributes of the drive in the four bytes preceeding the
drive queue entry.  If it's "locked in hardware" and removable then it's a
CD-ROM drive.

This fails because locked removable hard disks or optical media (or even
floppies) have the same attributes.  Some CD-ROM drivers allow you to
"write" to a CD-ROM drive (they shadow the file system and write the files
to a local hard disk, making the local hard disk appear as if it were part
of the CD-ROM drive.)

3) Issue a SCSI request directly to the drive.

This fails for some early CD-ROM drives (non-SCSI-2 compliant). Before
SCSI-2, there was no CD-ROM device type defined.  Some CD-ROM drives
reported back that they were disks instead.  You also have the
complication of SCSI Manager 4.3 today, and the possibility of IDE CD-ROM
drives in the future.  The IDE Manager has a completely different calling
architecture, and I couldn't tell you how to identify IDE CD-ROM drives
yet, because I haven't seen any yet.

4) Issue a ReadTOC() call to the driver and see if the result that comes
back is reasonable.

Although a Control() call with csCode 100 is a "famous" CD-ROM driver
call, there is nothing which prevents other drivers from implementing that
call.  In practice, few do, but it is entirely possible for a different
driver to implement that call with different values in csParam.  This can
be disasterous.

If I were trying to detect a CD-ROM drive, I'd take approach 4.  For each
mounted drive, issue a ReadTOC call to the driver for that drive.  If you
get back reasonable results, then you're probably talking to a CD-ROM
drive.

References:

DV 22, CD-ROM Driver Calls
Inside Macintosh:Devices, SCSI Manager 4.3 chapter
Developer Note on Quadra 630, IDE Manager

--
--Brian Bechtel    [e-mail]    "My opinion, not Apple's"
  Village Idiot, DTS

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

>From [e-mail] (Marshall Clow)
Date: Tue, 10 Oct 1995 20:37:50 -0700
Organization: Aladdin Systems

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

>Is there a way to walk the volume list and identify those volumes which are
>CDs? TIA.
>je

Not really.

You can look for large read only volumes.
-- Of course, locked ZIP drives can qualify

You can look for volumes that use the driver '.AppleCD'
-- But third party CD players may not use Apple's driver

You can apply other heuristics.

But AFAIK, there is no way to positively identify a CD.


-- Marshall

--
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

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

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