Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-110.txt

Text File | 1994-12-08 | 50.0 KB | 1,370 lines | [TEXT/R*ch]

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

Today's Topics:

    using stdio on a mac
    ResEdit - estr and hrct templates
    Color QD Pattern Alignment
    ADB Extended Keycodes
    C video application
    Mac Programming Primer
    SetHandleSize corrupts block?
    GWorlds & XCMDs
    Forcing CTB Serial Connection to close - How?
    Trying to get an overview of MacApp 3.0 classes: 2 quick questions
    Launching an appe


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 [e-mail].

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

Organization: Freshman, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA
Date: Tue,  5 May 1992 13:23:48 -0400
From: Peter William Wieland <[e-mail]>
Subject: using stdio on a mac

Is there any way to convert mac file references into C FILE pointers?
I've got some filter routines written using C that I'm trying to slap a
file-picker on.  I've seen code to get the full path name for a file,
but since Str255's  can't exceed 255 characters, that kind of limits the
pathnames.  Does anyone have any suggestions and/or sample code?

thanx

Peter Wieland        [e-mail]

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

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Wed, 6 May 1992 20:51:04 GMT

In article <[e-mail]>, Peter William Wieland <[e-mail]> writes:

> Is there any way to convert mac file references into C FILE pointers?
> I've got some filter routines written using C that I'm trying to slap a
> file-picker on.  I've seen code to get the full path name for a file,
> but since Str255's  can't exceed 255 characters, that kind of limits the
> pathnames.  Does anyone have any suggestions and/or sample code?

Several solutions come to mind.  One general solution for the long path
name problem is to periodically open a working directory on the path name
so far, then SetVol this to be the current volume, then proceed with the
remainder of the path name.  The working directories then become a kind
of "stepping stone" to the final file.  This is expensive because you are
creating and destroying all these directories each time.  The worst case
is when you do this for EVERY folder on the path.

If the file is already open, you could use PBGetFCBInfo to extract the
filename and ioVRefNum, then SetVol to that ioVRefNum, then open the bare
filename with the C open routine.

If you are starting out with a vRefNum/dirID/filename triple you might
make a working directory (using PBOpenWD) out of the vRefNum/dirID,
then SetVol to the WDRefNum you made, then use the C open routine to open
the bare filename.

BTW it is "clean" to PBCloseWD any WD you might make, and to use GetVol
and SetVol to save and restore the "current volume (folder)" around the
open code.

See also Tech Note 246 "Mixing HFS and C File I/O".


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

Organization: Freshman, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA
Date: Thu,  7 May 1992 15:40:13 -0400
From: Peter William Wieland <[e-mail]>

Thanks to everyone who responded to my original post.  Of all the
solutions, the best one I found was to hack Think c's stdio routines
(fopen, freopen, __open) to use a vRefNum along with the full pathname
(it ususally sets the ioVRefNum to zero).  Thanks for the help.

peter wieland                    [e-mail]

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

From: [e-mail] (Kevin Mitchell)
Subject: ResEdit - estr and hrct templates
Date: 6 May 92 09:24:20 GMT
Organization: Department of Computer Science, University of Edinburgh, UK

I was reading the Think C manual, and some of the class libraries mentioned
using estr and hrct resources.  My copy of ResEdit 2.1.1 doesn't have a
template editor for these resources.  Are these resource types just alternative
names for existing types, i.e. I can create them using some other template
editors, or am I missing some templates?

Any help would be appreciated.

Kevin

Kevin Mitchell                   JANET: [e-mail]
LFCS, Dept. of Computer Science  ARPA:  [e-mail]
University of Edinburgh
Edinburgh EH9 3JZ, UK.           Tel:   (+44) (0)31-650-5195

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

From: [e-mail] (Mike Hennahane)
Date: 7 May 92 23:56:10 GMT
Organization: CS Department, Stanford University, California, USA

[e-mail] (Kevin Mitchell) writes:

>I was reading the Think C manual, and some of the class libraries mentioned
>using estr and hrct resources.  My copy of ResEdit 2.1.1 doesn't have a
>template editor for these resources.  Are these resource types just alternative
>names for existing types, i.e. I can create them using some other template
>editors, or am I missing some templates?

i think that the manual states that estr is just the same as a pascal
str resource (but used for error strings). you could open as a str or
create a duplicate of the str template called estr. i'm not sure about
the hrct resource offhand.

- --mike

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

From: [e-mail] (Jim Cathey)
Subject: Color QD Pattern Alignment
Date: 6 May 92 18:32:09 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In the non-color QD world, patterns were always byte-aligned with the
bit image they were placed upon (unless you fiddled with the QD global
PatAlign).  Apparently this is no longer true under Color QD (using
CGrafPorts, etc).  Our native system shares the original QD pattern
behavior, and our paint application accounts for this behavior when it
is painting with patterns.  However, when this application displays
its windows on the Mac via our relay application (and the network) we
get misaligned patterns on systems with Color QD.  I've tried fiddling
with PatAlign (a long at -0xA8 offset from (a5)) --- no joy.  I don't
see _any_ mention of pattern alignment in IMV, nor in the Tech Notes.
Any suggestions?

- --
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

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

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 May 92 06:08:38 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jim Cathey) writes:
> In the non-color QD world, patterns were always byte-aligned with the
> bit image they were placed upon (unless you fiddled with the QD global
> PatAlign).  Apparently this is no longer true under Color QD (using
> CGrafPorts, etc).

It seems to me the more natural way to do it would be if "patterns are always
aligned on coordinates which are multiples of their dimensions". Black-and-
white patterns are always 8-by-8, but, for example, if you had a colour
pattern which was 32 pixels wide and 16 tall, then it would be aligned on
multiples of 16 pixels vertically and 32 horizontally.

I must go home and check this. But honestly, I can't imagine that Color
QuickDraw would be so brain-damaged as to do things any other way. :-}

> Our native system shares the original QD pattern
> behavior, and our paint application accounts for this behavior when it
> is painting with patterns.  However, when this application displays
> its windows on the Mac via our relay application (and the network) we
> get misaligned patterns on systems with Color QD.

So you're passing the pattern definition over the network, followed by
a command to draw with that pattern? If my assumption above is right,
you should be able to get the patterns to line up simply by making sure
that the window/grafport origin is always set consistently at both ends.

> I've tried fiddling
> with PatAlign (a long at -0xA8 offset from (a5)) --- no joy.

Interesting. So fiddling patAlign has *no* effect on colour patterns?
(I guess the way to check that you're doing it correctly is to watch
for the effect on B&W patterns).

> I don't
> see _any_ mention of pattern alignment in IMV, nor in the Tech Notes.
> Any suggestions?

I think it would be really nice if somebody in the know could explain to us
this business about patAlign once and for all. Any takers?

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
                       Signature tow-away zone. You have been wa

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

From: [e-mail] (Simon Lucas)
Date: 7 May 92 08:49:47 GMT
Organization: Kingston Polytechnic

Subject: StringPtrs in MacApp2.0.1/C++
Newsgroups: comp.sys.mac.programmer
Distribution: world

Probably a FAQ or generally stupid question, but I have tried evrything
I can think of to solve this. I'm trying to get used to C++ without
much luck and with much frustration.
I've consulted every manual and book I have but the subject is not covered.
PLease help. CODE frags included at end:

I need to save the strings from a dialog in my document object. Simple??
To do this I figured using Pascal strings would be easiest and am using
StringPtr types. This works fine when using GetText or SetText.
However, when I try and copy the strings to a struct in order to write them
to disk I get a bus error:

Q1. Would I be right in assuming that memory reallocation is causing the
dangling string pointers inside the doc object? and why doesnt it happen when
using GetText?
Q2. What is the correct (or more correct) way to deal with this problem?
- - Do I have to resort to char arrays and then do lots of c2pstr's and vice
versa? Would using global StringPtrs be a better way?
Q3. In general what are the rules vis-a-vis pointers inside objects? Does
MacApp lock down objects to prevent dangling pointers or should the programmer
be doing this?

CODE FRAGMENTS:-
// doc class
class TNewGateDoc : public TDocument {
  public:
    StringPtr fStrRad1;
    StringPtr fStrRad2;
    // etc..
    TControlView fControlView;
    TMainView fMainView;
    // etc....
}

// saving the strings via GetText works ....
pascal void TNewGateDoc::GetValues(void)
{
    ((TEditText *)fControlView->FindSubView('Rad1'))->GetText(fStrRad1);
    // etc....
}

// i declare a type to collect the strings into a struct for writing to disk:

typedef struct {
    StringPtr StrRad1;
    StringPtr StrRad2;
    / etc....
} GateDocDiskInfo;

// then try copying the strings into the struct:

pascal void TNewGateDoc::DoWrite(short aRefNum, Boolean makingCopy)
{
    GateDocDiskInfo aDiskInfo; // data structure for writing to disk
    long nBytes = sizeof(GateDocDiskInfo); //number of bytes to be written

    aDiskInfo.StrRad1=PLstrcpy(aDiskInfo.StrRad1,fStrRad1); // BUS ERROR!!!!
    aDiskInfo.StrRad2=PLstrcpy(aDiskInfo.StrRad2,fStrRad2);
    /etc..
}

thanks for any help..

Simon Lucas

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

From: [e-mail] (Jim Cathey)
Date: 7 May 92 19:41:56 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>It seems to me the more natural way to do it would be if "patterns are always
>aligned on coordinates which are multiples of their dimensions". Black-and-
>white patterns are always 8-by-8, but, for example, if you had a colour
>pattern which was 32 pixels wide and 16 tall, then it would be aligned on
>multiples of 16 pixels vertically and 32 horizontally.

This would make sense.  The patterns should end up tiled across the pixel
image, starting at the first pixel in the image.  This would be equivalent
to what happens in the B&W world.

>> Our native system shares the original QD pattern
>> behavior, and our paint application accounts for this behavior when it
>> is painting with patterns.  However, when this application displays
>> its windows on the Mac via our relay application (and the network) we
>> get misaligned patterns on systems with Color QD.
>
>So you're passing the pattern definition over the network, followed by
>a command to draw with that pattern? If my assumption above is right,
>you should be able to get the patterns to line up simply by making sure
>that the window/grafport origin is always set consistently at both ends.

Yes.  The application does its own offscreen drawing using 8x8 patterns
that are aligned with (tiled from) 0,0 of that image.  It also whips up
another pattern to match the fill pattern, the new one is rotated up to
7 pixels on each axis (the LocalToGlobal offset of the coordinate system
of the window modulo the pattern size) so that when it is used (in
FillRect, say) the on-screen fill will match what happened offscreen.
To draw on-screen, the application mixes pattern drawing calls with
CopyBits's of its offscreen image, depending on what it is doing.  On a
B/W Mac, all this merges seamlessly.  On a machine with Color QD, the
patterns don't merge.  (They _do_ merge if I use NewWindow instead of
NewCWindow, but that's not a solution, since this thing needs to draw in
color, too).

It _appears_ that a CGrafPort's patterns are aligned with the start of
the portRect, instead of with the pixMap.bounds rectangle.  If so, I'm
going to have to mangle the pattern myself before each drawing call that
uses a pattern, in order to shift it to align with the pixel image ---
effectively un-doing what the application had to do in the first place
to deal with non-color Macs (and our native systems).  Blech.

>Interesting. So fiddling patAlign has *no* effect on colour patterns?
>(I guess the way to check that you're doing it correctly is to watch
>for the effect on B&W patterns).

I didn't check it this thoroughly.  I disassembled (using ResEdit's CODE
disassembler) the standard WDEF 0 to find out where PatAlign was, since
I have (from ftp.apple.com) the source to WDEF 0, but not the include
files that declare the offsets.  (WDEF 0 uses PatAlign to draw the lines
in the title bar as a single pattern-filled rectangle.)

- --
+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

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

From: [e-mail] (Jon Pugh)
Subject: ADB Extended Keycodes
Date: 6 May 92 19:44:30 GMT
Organization: Apple Co.

I'm trying to get the extended keyboard to return extended keycodes for the
duration of a GetKeys call so that I can tell the difference between the
right and left shift, control and option keys.  Since I have written an LED
XCMD, I figured this would be easy given my existing ADB code.  Sure enough,
I can change register 3 as IMV-193 says to, but it doesn't seem to work
properly.

The trick is that register 3 contains a word with the high byte containing
state info, including the address, and the low byte containing the device
handler ID, which is normally 2 and should be 3 for extended keycodes.
The documentation on register 3 (IMV-365) says that you need to get the
whole word, change the low byte and set it to this, so I do that, but I
suspect that some of the high nibble shouldn't be messed with, but I don't
know how to avoid it or if that is really true.  All I know is that I cannot
return the keyboard to its original state (reboot!). It seems to behave like
the right hand shift key is locked down.

My friends in DTS claim that the ADB guys all dropped off the face of the
earth and/or never really existed in the first place. Does anyone have any
experience messing with this crap or am I in the weeds again?

Jon

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

From: [e-mail] (Jon Pugh)
Date: 7 May 92 20:44:58 GMT
Organization: Apple Co.

In article <[e-mail]>, I (Jon Pugh) write:
>
> My friends in DTS claim that the ADB guys all dropped off the face of the
> earth and/or never really existed in the first place. Does anyone have any
> experience messing with this crap or am I in the weeds again?

In actuality all the ADB guys went to Pink.

My other friends in DTS (you can't whine at everyone all the time) came
to the rescue to point out that there is sample code on the Dev CDs.

Of course, mine does the same stuff, so we're hoping it's merely a latency
problem.  A couple of Delay calls should determine the truth of this rumor.

Jon

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

From: erich@rodan (Eric Hilfer)
Subject: C video application
Date: 7 May 92 13:38:45 GMT

I am planning to write a Mac application in C that will provide a simple
interface to a digitized video image.  This is my first Mac
programming project, but I have lots of experience writing
X-Windows applications under Unix.  I would like some general advice
on how to do the following:

1) What is a good choice for a compiler?  I've heard Think C
recommended.

2) Are there any special tricks to let my application get the
coordinates of a mouse click that occurs in another application's
window?  The user will display digitized video in a window using the
viewing software that came with the digitizing card.  Then the user
will launch my application, and point and click in the video graphics
window.  The coordinates of the clicks (relative to the viewing
software's window) will be saved by my application as data.

3) I want the user to be able to send the accumulated list of
coordinates into other applications ( a commercial spreadsheet, for
example).  What is involved in supporting the ability to drag and drop
the list into another application?  How does the new Publisher/Subscriber
mechanism work?

Thanks in advance for your help!!

Eric


- --
- ----------------
Eric Hilfer
[e-mail]

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

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 May 92 06:54:26 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, erich@rodan (Eric Hilfer) writes:
> I am planning to write a Mac application in C that will provide a simple
> interface to a digitized video image.  This is my first Mac
> programming project, but I have lots of experience writing
> X-Windows applications under Unix.  I would like some general advice
> on how to do the following:

[I'll let someone else answer the question about a good choice of C compiler,
as I tend to avoid C myself :-)]

> 2) Are there any special tricks to let my application get the
> coordinates of a mouse click that occurs in another application's
> window?  The user will display digitized video in a window using the
> viewing software that came with the digitizing card.  Then the user
> will launch my application, and point and click in the video graphics
> window.  The coordinates of the clicks (relative to the viewing
> software's window) will be saved by my application as data.

I have a better idea: use the standard QuickTime interface (which is supported
by most video input cards these days) so you can display the live video in one
of your own windows, and you can handle clicks without any special tricks.

(Hey, that rhymes...)

> 3) I want the user to be able to send the accumulated list of
> coordinates into other applications ( a commercial spreadsheet, for
> example).  What is involved in supporting the ability to drag and drop
> the list into another application?  How does the new Publisher/Subscriber
> mechanism work?

Publish and Subscribe is a method for maintaining "live" links, such that
any changes in the original data are automatically propagated to all
subscribers. I might be wrong, but it seems to me that you really just want
to accumulate a list of coordinates, move them into a document, generate
another list, move that into a (possibly different) document, and so on.
Doing this is easy: you just need to support copy-and-paste. The technical
details are documented in Chapter 15 ("The Scrap Manager") of Inside Mac Vol I.

You *do* have the full set of Inside Mac volumes I-VI, don't you...?

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
X Windows: distributed computing in reverse.

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

From: [e-mail] (Terry Spurling)
Subject: Mac Programming Primer
Organization: Massachusetts Institute of Technology
Date: Thu, 7 May 1992 16:09:18 GMT

I am new to Macintosh C programming and am using the Mac Programming Primer with Think C 5.0 and when I use their pointer for window placement:

#define MOVE_TO_FRONT -1L

I get the error:

last argument to function 'GetNewWindow' does not match prototype.


Can anyone provide me with an explanation and, if possible, the new value for that pointer.


thanx

- -terry spurling



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

From: [e-mail] (Terry Spurling)
Organization: Massachusetts Institute of Technology
Date: Thu, 7 May 1992 19:55:30 GMT

Thanx to everyone whoo responded to the MOVE_TO_FRONT pointer question I had.  I now have several ways to overcome my problem.!!!!!


THANX LODES
- -terry


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

From: [e-mail] (Matt Mora)
Date: 8 May 92 15:22:49 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Terry Spurling) writes:
>I am new to Macintosh C programming and am using the Mac Programming Primer with Think C 5.0 and when I use their pointer for window placement:

>#define MOVE_TO_FRONT -1L

>I get the error:

>last argument to function 'GetNewWindow' does not match prototype.

Try #define MOVE_TO_FRONT (WindowPtr) -1L

I think you have the Check Pointer types option on in the compiler settings.
Since -1L does not equal a WindowPtr (which is what GetNewWindow wants)
you have to cast it to a WindowPtr type.


Matt



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

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

From: [e-mail] (The Anarch)
Subject: SetHandleSize corrupts block?
Date: 7 May 92 17:21:15 GMT
Organization: Secular Humanists from Hell


     Has anyone encountered corrupted data as a result of using SetHandleSize?
It *is* supposed to maintain the contents of the current block, right?  I've
always assumed this, and it seemed to work pretty well in the past, but I
notice that Inside Mac doesn't actually *say* that it does, and something is
definitely going wrong for me now.  I'm using SetHandleSize to enlarge a
block, and though the call succeeds, some of the data from before gets changed
(the pieces I've looked at get changed to 0, but I haven't gone through the
entire block).  I've looked through the technical info available to me (tech
notes, Inside Mac) and asked a few people and haven't found any explanation
yet.  I'd appreciate whatever advice people here can offer.  This is Think C
5.0.1 on a IIfx, Sys 7.0, no INITs, no virtual memory, both 24 and 32 bit
addressing.  Thanks!

- --
[e-mail]-+-+-+-+-+-+-+-+-+-+-+-+-+
   "The Walpurgisnacht has become synonomous with any general revelry, and
     particularly for the breaking out of demonic lewdness and disorder."
D I S C L A I M E R :   E V E R Y T H I N G   I   W R I T E   I S   F A L S E

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

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

In article <[e-mail]>,
[e-mail] (The Anarch) writes:
>
>
>      Has anyone encountered corrupted data as a result of using SetHandleSize?
> It *is* supposed to maintain the contents of the current block, right?  I've
> always assumed this, and it seemed to work pretty well in the past, but I
> notice that Inside Mac doesn't actually *say* that it does, and something is
> definitely going wrong for me now.  I'm using SetHandleSize to enlarge a
> block, and though the call succeeds, some of the data from before gets changed
> (the pieces I've looked at get changed to 0, but I haven't gone through the
> entire block).  I've looked through the technical info available to me (tech
> notes, Inside Mac) and asked a few people and haven't found any explanation
> yet.  I'd appreciate whatever advice people here can offer.  This is Think C
> 5.0.1 on a IIfx, Sys 7.0, no INITs, no virtual memory, both 24 and 32 bit
> addressing.  Thanks!

SetHandleSize _does_ preserve the contents of the data block when you make the
block larger. Most applications and the system itself relies on this fact.

What immediately comes to mind when I read your problem is that perhaps the
handle is not as large as you think it is when you grow it. In that case, the
bytes you are losing may not actually be bytes that you own.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


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

From: [e-mail] (The Anarch)
Date: 7 May 92 23:52:10 GMT
Organization: Secular Humanists from Hell

I asked for advice about SetHandleSize corrupting data, and
in article <[e-mail]> [e-mail] (Keith Rollin) replied:
>SetHandleSize _does_ preserve the contents of the data block when you make the
>block larger. Most applications and the system itself relies on this fact.
>
>What immediately comes to mind when I read your problem is that perhaps the
>handle is not as large as you think it is when you grow it. In that case, the
>bytes you are losing may not actually be bytes that you own.

     Not quite, but close--turns out I wasn't asking for as much as I thought.
Misplaced parentheses and some tricky operator precedence will do it every
time.  Sigh...somehow, as soon as I put it onto the net, I knew it would turn
out to be something stupid.  But thanks for your help--I probably wouldn't
have noticed for days without it.

- --
[e-mail]-+-+-+-+-+-+-+-+-+-+-+-+-+
   "The Walpurgisnacht has become synonomous with any general revelry, and
     particularly for the breaking out of demonic lewdness and disorder."
D I S C L A I M E R :   E V E R Y T H I N G   I   W R I T E   I S   F A L S E

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

From: [e-mail] (Mike Diehr)
Subject: GWorlds & XCMDs
Date: 7 May 92 22:00:46 GMT
Organization: Philips Interactive Media


The following code is <most> of an XCMD I`m writing.  The goal
is to take a COLOR snapshot of the screen and do two things with it:
(1) make a COLOR PICT
(2) convert to another file format.

To do this, I thought that I'd simply create a new 32 bit GWorld, then
Open a picture, CopyBits() from the screen to the new GWorld, and
finally close and save the picture.  Then, I could use the 32 bit
GWorld to do my own file transformation.

However, I'm having trouble accessing the screen.  I have a simpler
version which simply uses OpenCPort(), and this works fine.  I think
I'm having problems with the GWorld stuff.  I'm not trying to access
PixMaps directly, so I don't see why it should be so difficult.
(Note: I am using Spectrum PDQ 24 bit accelerated color card, so
 I must be careful about doing the GWorld stuff correctly, no?)

Some Question:
(1) can I access QuickDraw globals (i.e. thePort) from a XCMD
 (I'm using Think C 5.0.2)
(2) How do I ensure that OpenPicture will create a color pic?
  or do I have to use OpenCPicture?
(3) as you can see below, I'm having trouble with the CopyBits command.
   which form is correct?

thanks!




#define CLEAN_UP_GWORLD    SetGWorld(savePort, saveDevice);    \
                UnlockPixels(gWorld->portPixMap);        \
                DisposeGWorld(gWorld)



#define PICTHEADERSIZE 512

#define NIL            0L
#define MINPARAMS    4
#define MAXPARAMS    5

Str255 GErrStr;
int        GUseGErrStr = FALSE;

pascal void main(XCmdPtr pp)
{
    CGrafPtr            theOldCPort;
    CGrafPtr        oldPort;
    CGrafPtr        newPort;
    RgnHandle        rgn;
    Rect            copyRect;
    PicHandle        pict;

    int                ParamNum;
    Str255            ParamStr;
    Rect            theRect, rect2;

    Str255            tempStr;
    Handle            tempHandle;
    Point            tempPoint;

    Point            p1,p2;

    Str255            fileName;
    Str255            fileType;
    Str255            iffTypeStr;
    int                iffType;
    int                doIffFile;
    OSType            fileCreator;


    /**************************
         GWorld stuff
    ***************************/
    GWorldPtr        gWorld;
    CGrafPtr        savePort;
    GDHandle        saveDevice;
    PixMapHandle     srcPm, destPm;


    RememberA0();
    SetUpA4();




    GetPort (&theOldCPort);


[ deleted the stuff to read the xcmd parameters ]




/*********************
     DO IT
 **********************/


     /****************************************
         Create a new 32 bit GWorld,
         lock it
     ****************************************/
     if (
         (NewGWorld(&gWorld, 32, &theRect, NULL, NULL, useTempMem | keepLocal) != noErr)

        )
    {

        SetErrorResult(pp, "Error creating GWorld");
        return;

    }

    /* remember the current GWorld */
    GetGWorld(&savePort, &saveDevice);
    /* set the GWorld to the new one, so that
        the picture routines can read it's pixels */
    SetGWorld(gWorld, NULL);


    if ( LockPixels(gWorld->portPixMap) == FALSE)
    {
        SetErrorResult(pp, "Error locking GWorld");
        return;
    }



    pict = OpenPicture(&theRect);
    if (!pict)
    {


        CLEAN_UP_GWORLD;

        SetErrorResult(pp, "Error creating PICT");
        return;
    }

    srcPm = GetGWorldPixMap(savePort);
    destPm = GetGWorldPixMap(gWorld);

    /* ARRGH, I don't know which one is right??? */

    //CopyBits((BitMap*) *srcPm, (BitMap*) *destPm,&theRect,&theRect,srcCopy,NIL);
    //CopyBits(&theOldPort->portBits, (BitMap*) *destPm,&theRect,&theRect,srcCopy,NIL);
    CopyBits( (BitMap*)*(theOldCPort->portPixMap), (BitMap*) *destPm,&theRect,&theRect,srcCopy,NIL);
    //CopyBits(&thePort->portBits, (BitMap*)*destPm,&theRect,&theRect,srcCopy,NIL);
    //CopyBits(&newPort->portPixMap,&newPort->portPixMap,&theRect,&theRect,srcCopy,NIL);

    ClosePicture();



        /********************
            Add PICT to resource
        **********************/

        AddResource(pict,'PICT',0,"\pTest Picture2");
        if (ResError())
        {
            SetErrorResult(pp, "Error creating PICT resource");

            //ClosePort(newPort);
            //DisposPtr(newPort);
            //SetPort(oldPort);
            CLEAN_UP_GWORLD;
            return;
        }

        ChangedResource(pict);
        WriteResource(pict);

        UpdateResFile(CurResFile());

        ReleaseResource(pict);

    }
    DisposeHandle(pict);


    /********************
        Clean Up
    ********************/
    CLEAN_UP_GWORLD;

    RestoreA4();
}


- -mike

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

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 8 May 92 19:22:43 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Mike Diehr) writes:

> Some Question:
> (1) can I access QuickDraw globals (i.e. thePort) from a XCMD
>  (I'm using Think C 5.0.2)

Yes, but you have to double-indirect from A5. That is, A5 itself points to a
longword which contains the address of the QuickDraw globals.

> (2) How do I ensure that OpenPicture will create a color pic?
>   or do I have to use OpenCPicture?

OpenPicture will do fine if the current port is a CGrafPort.

> (3) as you can see below, I'm having trouble with the CopyBits command.
>    which form is correct?
>
> #define CLEAN_UP_GWORLD    SetGWorld(savePort, saveDevice);    \
>                 UnlockPixels(gWorld->portPixMap);        \
>                 DisposeGWorld(gWorld)

You can save yourself the unlock call, if you're going to dispose of the
GWorld anyway.

>     GetPort (&theOldCPort);

>      if (
>          (NewGWorld(&gWorld, 32, &theRect, NULL, NULL, useTempMem | keepLocal) != noErr)
>
>         )
>     {
>
>         SetErrorResult(pp, "Error creating GWorld");
>         return;
>
>     }
>
>     /* remember the current GWorld */
>     GetGWorld(&savePort, &saveDevice);

Hmm, it seems to me you've now got a pointer to the card window GrafPort
in both theOldCPort and savePort. Surely you don't need both?

>     /* set the GWorld to the new one, so that
>         the picture routines can read it's pixels */
>     SetGWorld(gWorld, NULL);
>
>
>     if ( LockPixels(gWorld->portPixMap) == FALSE)
>     {
>         SetErrorResult(pp, "Error locking GWorld");
>         return;
>     }

Personally I prefer to lock the pixels BEFORE making the GWorld current.

>
>
>
>     pict = OpenPicture(&theRect);
>     if (!pict)
>     {
>
>
>         CLEAN_UP_GWORLD;
>
>         SetErrorResult(pp, "Error creating PICT");
>         return;
>     }
>
>     srcPm = GetGWorldPixMap(savePort);
>     destPm = GetGWorldPixMap(gWorld);

GetGWorldPixMap is known not to work correctly in 32-Bit QuickDraw 1.2
(Systems 6.0.x, x >= 5). (Did it work correctly in earlier versions?)
Of course, if your code will only run under System 7, that's no problem.
Otherwise, I'd suggest using:

    srcPm = savePort->portPixMap;
    destPm = gWorld->portPixMap;

(This code will only malfunction with black-and-white gworlds on non-colour-
capable machines--a feature new with System 7.)

>
>     /* ARRGH, I don't know which one is right??? */
>
>     //CopyBits((BitMap*) *srcPm, (BitMap*) *destPm,&theRect,&theRect,
>          srcCopy,NIL);

This one should work! However, I suspect you should lock down the pixmap
handles before doing this; I'm not sure if QuickDraw will do this for you.

>     //CopyBits(&theOldPort->portBits, (BitMap*) *destPm,&theRect,&theRect,
>          srcCopy,NIL);

Yes, this one should work too. You can always pretend that a CGrafPort is
a GrafPort, pass the address of its portBits field, and QuickDraw will do the
right thing. My worries about locking pixmaps still apply to the second
argument.

>     CopyBits( (BitMap*)*(theOldCPort->portPixMap), (BitMap*) *destPm,
>          &theRect,&theRect,srcCopy,NIL);

Should work, provided pixmaps are locked.

>     //CopyBits(&thePort->portBits, (BitMap*)*destPm,&theRect,&theRect,
>          srcCopy,NIL);

Ditto.

>     //CopyBits(&newPort->portPixMap,&newPort->portPixMap,&theRect,&theRect,
>          srcCopy,NIL);

No, I don't think you can pass a pixmap handle; it must be a pointer to
an actual bitmap or pixmap.

[rest of the code looks OK]

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
Brought to you by Chemical Computing, Inc: We may not have the solution,
but at least we can provide the solvent.

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

From: [e-mail] (Tom Johnson)
Subject: Forcing CTB Serial Connection to close - How?
Organization: UCLA Computer Science Department
Date: Fri, 8 May 92 06:13:36 GMT

A question for the CTB experts out there:

How can you force the CTB to close a serial connection and free up a
serial port when you no longer have a ConnHandle and can't call CMClose?

Background:  I'm working on an application that uses the CTB for serial port
connections.  Every once in a while I'll crash my mac during development and
when I try to relaunch my application and open up the serial port again,
I get a "Sorry that port is busy" error dialog, since I was never able to
call CMClose.  I would like to throw together a quick FKEY or an application
that forces all serial connections to close, so I don't have to reboot my
machine before I get back to work.

Any ideas?

Thanks-
  Tom
- --
Tom Johnson             "They say Confucious does his crossword with a pen."
[e-mail]                               -Tori Amos

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

From: [e-mail] (Bill Lipa)
Date: 8 May 92 07:16:31 GMT
Organization: Stanford School of Medicine

In article <[e-mail]> [e-mail] (Tom Johnson) writes:
>How can you force the CTB to close a serial connection and free up a
>serial port when you no longer have a ConnHandle and can't call CMClose?
>Background:  I'm working on an application that uses the CTB for serial port
>connections.  Every once in a while I'll crash my mac during development and
>when I try to relaunch my application and open up the serial port again,
>I get a "Sorry that port is busy" error dialog, since I was never able to
>call CMClose.

I think that holding down the option or control key will turn the OK in that
dialog to Override. However, a more significant problem you may face might
be crashes from subsequent CTB calls after an app crashes. The CTB does not
properly clean up in this case. You HAVE to call CMClose if you want
reliable operation in later apps. This makes development an incredible pain.

I debug my CTB apps with sanity intact by having a routine called terminate.
This is a panic exit function that calls CMClose for me. When my program
crashes, I get into MacsBug and type "g terminate". Most of the time, this
works pretty well.

Bill Lipa
[e-mail]

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

From: [e-mail] (opcode ranger)
Subject: Trying to get an overview of MacApp 3.0 classes: 2 quick questions
Date: 30 Apr 92 03:31:53 GMT

Two quick MacApp (3.0) questions:

I'm looking for some overview of the MA class hierarchy, and it occurred to me
that parsing the library code (.cp files) with MacBrowse would be a good idea.
It all seemed to parse fine(i.e. it said it was parsing all the U*.cp files),
but it only shows me the global routines and a couple of other classes, but not
most of them.  What gives?

Also, in the MacApp tutorial and/or programmer's guide there is reference made
to some sort of MacApp reference that details all the MA classes (I don't have
the manuals on me so I can't look up the exact title).  Is there such a beast?
I don't recall having gotten anything like that with my ETO shipment.


Thanks for any help! (email would be best since my line charges are high to read
this group).

Robert

- --
==============================================================================
= [e-mail] * "Out there on a darkened road, the lights =
= are dead and the cars explode" -- "Good Things", Sisters of Mercy           =
==============================================================================

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

From: [e-mail] (Cory Kempf)
Date: Thu, 7 May 92 21:50:32 EST
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (opcode ranger) writes:
>Two quick MacApp (3.0) questions:
>
>I'm looking for some overview of the MA class hierarchy, and it occurred to me
>that parsing the library code (.cp files) with MacBrowse would be a good idea.

There is a chart that was in one of the manuals that came with ETO
7 that shows all of the MacApp classes and their inheritance, as well
as some other commonly needed info.  This may be what you are looking
for.  As I remember, it was tucked into the release notes, but I am
not positive.

>Also, in the MacApp tutorial and/or programmer's guide there is reference made
>to some sort of MacApp reference that details all the MA classes (I don't have
>the manuals on me so I can't look up the exact title).  Is there such a beast?
>I don't recall having gotten anything like that with my ETO shipment.

There is a Programmer's Guide to MacApp, but it really sucks.  It
gives the most cursory overview of the classes, and how they are to
be used, but the examples are trivial at best, and most of the classes
are missing.

What MacApp really needs is good documentation.  I am trying to learn
MacApp / write a small program in it, and I spend most of my time
trying to trace the source code.  A good set of Unix-style man pages
for each class (preferably with each one duplicating the info in the
super classes) would be ideal!  411's MacApp support is a joke.  70%
of the time, I cannot find methods / constants / datatypes that MacApp
uses, and the rest, I can almost never select some of my code and
get anywhere with MacApp like I can with the toolbox.

If Apple really wants people to use MacApp, good docs & 411 support
are essential!

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

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

From: [e-mail] (Brian Hall)
Subject: Launching an appe
Date: 30 Apr 92 06:12:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Anyone know of a way to launch an 'appe' (background only) application
at a time other than startup?  ('appe's live in the extentions folder)

- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | People don't kill people, toasters kill people.

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

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Thu, 30 Apr 92 16:49:21 GMT

In article <[e-mail]> [e-mail] (Brian Hall) writes:
>Anyone know of a way to launch an 'appe' (background only) application
>at a time other than startup?  ('appe's live in the extentions folder)
>
    Sure, same way you'd launch an application - call _LaunchApplication.
The only thing "special" about the 'appe' is that the Finder knows where
to put them & they can be launched at startup.  You can even put an 'appe'
inside something else (like a cdev) and have it launched - the new version
of Rival does this so that it can recieve anti-viral Apple events.


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

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

From: [e-mail] (Ross Brown)
Date: 1 May 92 14:06:39 GMT
Organization: Bell-Northern Research

In article <[e-mail]>
[e-mail] writes:
>In article <[e-mail]> [e-mail] (Brian Hall) writes:
>>Anyone know of a way to launch an 'appe' (background only) application
>>at a time other than startup?  ('appe's live in the extentions folder)
>>
>    Sure, same way you'd launch an application - call _LaunchApplication.
>The only thing "special" about the 'appe' is that the Finder knows where
>to put them & they can be launched at startup.  You can even put an 'appe'
>inside something else (like a cdev) and have it launched - the new version
>of Rival does this so that it can recieve anti-viral Apple events.

This is a topic of much interest.  Not everyone has access to d e v e l o p.
Can anyone summarize all the differences between 'appe's and 'APPL's for the
benefit of this newsgroup?

Specifically, I want to know:  Can 'appe's have bundles and be launched by the
Finder when the user double-clicks on an associated file?

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.

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

From: [e-mail] (Milton Sagen)
Date: 5 May 92 18:08:54 GMT
Organization: TECHbooks of Beaverton Oregon - Public Access Unix

In article <[e-mail]> [e-mail] (Ross Brown) writes:
>This is a topic of much interest.  Not everyone has access to d e v e l o p.

Speaking of d e v e l o p, I haven't received a copy since the autumn 1991
edition.  Anybody else having problems?  Was this the last issue everbody
else received?  Who should I call to check on this?  APDA?

I apologize for the interruption.  I now return you to our regular programming.
- --
Milton E. Sagen                          [e-mail]
Software Engineer                        !{sequent,nosun,uunet}techbook!sagen
Prometheus Products, Inc.                [phone] (voice)
Tualatin, OR 97062                       [phone] (fax)

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

From: [e-mail] (Gavin Eadie)
Date: 6 May 92 14:58:51 GMT
Organization: University of Michigan

I've been developing a background application framework which I plan to
use for a collection of small collaborating tasks.  In doing this work, I
learned a few things about these beasts.

First, though we might call them 'appe's that doesn't have to be the file
type of the application. Mine are all regular 'APPL' files and that seems
to work just fine.  I launch them via the Finder by double click or
menu-'Open'.

They are totally invisible while running, they don't show in the 'About
This Macintosh...' display, they don't show in the application menu on
the top right of the screen.  Mine just still there, quiet as mice, and
take tiny slices of CPU time every 10 seconds.  The only way to find them
is via Process Manager calls in a litle app like NoFinder (which displays
a list of running apps, including faceless ones, and let's you quit
them).  You need something like NoFinder to cause them to stop by the way
- - or use Frontier and send them a 'quit' AppleEvent.

There's one strangeness that I've noticed.  If you launch a
background-app from the Finder, the icon of the application goes grey as
it launches.  It stays grey after you kill the running application - I
assume Finder has no way to restore the solid icon of the app because it
has no idea the background app has been stopped.  Similarly, of course,
if you use Frontier to launch a background app, the Finder doesn't grey
it's icon.

I think the potential for these little apps is pretty exciting. What
background processes would you want to run on your Mac all day, every
day?!
===
Gavin Eadie, Ramsay Consulting

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

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Wed, 6 May 1992 15:45:44 GMT

In article <[e-mail]> [e-mail] (Gavin Eadie) writes:
>There's one strangeness that I've noticed.  If you launch a
>background-app from the Finder, the icon of the application goes grey as
>it launches.  It stays grey after you kill the running application - I
>assume Finder has no way to restore the solid icon of the app because it
>has no idea the background app has been stopped.  Similarly, of course,
>if you use Frontier to launch a background app, the Finder doesn't grey
>it's icon.

The finder restores the solid icon of the app as soon as possible after the
DrawMenuBar() trap is called, if some manager (which one I can't remember,
but it's not QuickDraw) is inited. Hence, a FBA will never call DrawMenuBar,
and so the finder doesn't know to solidify the icon. At least, this is how
it was explained to me.


- --
+------------------------------+---------------------------------------------+
+ Mel Walker                   | ******** Dave Barry for President ********  +
+ [e-mail] |  "A clever slogan should be written here"   +
+------------------------------+---------------------------------------------+

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

From: [e-mail] (Brian Hall)
Date: 6 May 92 19:48:39 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Gavin Eadie <[e-mail]> writes:

>I've been developing a background application framework which I plan to
>use for a collection of small collaborating tasks.  In doing this work, I
>learned a few things about these beasts.

>First, though we might call them 'appe's that doesn't have to be the file
>type of the application. Mine are all regular 'APPL' files and that seems
>to work just fine.  I launch them via the Finder by double click or
>menu-'Open'.

I have been using a little app I found on America Online called
Processorize to launch and kill my background apps.  I'll have to try
your trick though.

Any thoughts on how to use a symbolic debugger on these beasts?  I'm using
Think C 5.0 and it just chokes if I "run" the project instead of building
the app to disk and then launching it.  I have gone back to mid-80's style
debugging.  Lots of DebugStr calls.  ICK!


- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | People don't kill people, toasters kill people.

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

From: [e-mail] (Pete Gontier)
Date: 9 May 92 01:42:13 GMT

In <[e-mail]> [e-mail] (Ross Brown) writes:
>Specifically, I want to know:  Can 'appe's have bundles and be launched by the
>Finder when the user double-clicks on an associated file?

No. Unfortunately, I don't have the sort of generalized info you want.
But I do know that Kiwi(tm) POWER WINDOWS would have one less installed file
if I could have gotten documents to launch into an (open) 'appe'.
- --
 Pete Gontier // EC Technology // [e-mail]

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

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