From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-088
Date: Mon, 13 Mar 1995 13:22:32 +0100 (MET)
C.S.M.P. Digest Mon, 13 Mar 95 Volume 3 : Issue 88
Today's Topics:
Asynchronous Programming?
Distinguishing QT-compressed PICTs
Getting TEHandle from dialog item number
How to get a CLUT from a PICT file?
I need gWorlds??
IP --> Name translation
LDEFs - HOW?
ShowDragHilite -- a real drag?
The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
(pottier@clipper.ens.fr).
The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions. If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail help@anon.penet.fi 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 listserv@ens.fr
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
scott.silver@dartmouth.edu.
-------------------------------------------------------
>From Said Kobeissi <said.kobeissi@together.org>
Subject: Asynchronous Programming?
Date: 23 Feb 1995 15:57:07 GMT
Organization: TOGETHER INTERNET SERVICES
Hi all,
Can anyone give me a pointer to examples or references for
learning how to program asynchronous routines? I want to do
some multitasking but being new to the Mac, have no idea where
to start.
Greatly aprpeciate it..
Said
said.kobeissi@together.org
+++++++++++++++++++++++++++
>From oster@netcom.com (David Phillip Oster)
Date: Fri, 24 Feb 1995 02:44:18 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
In article <3iib8j$2g0@bristlecone.together.net> Said Kobeissi <said.kobeissi@together.org> writes:
> Can anyone give me a pointer to examples or references for
>learning how to program asynchronous routines?
look in develop issue 17 (March 1994) "Concurrent programming with the Thread
Manager", particularly "Thread Blocking I/O", on page 90.
develop is on the Reference Library volume of the Developer's CD, and is
also available separately from APDA. I would ignore the article on the
Thread Manager in a recent Mactech.
Also, check out a good theory of computing book on state machines. The problem
with using the Thread Manager with asynchronous routines is:
o If you use pre-emptive threads, you won't run on a PowerMac, and you'll
still have the usual resource problems that interrupt routines have on the
mac.
o If you use only co-operative threads, then your i/o completion routine
will mostly just set some thread to "ready" and it will push things along
at the next co-operative thread Yield(). This can be a problem, since
this thread will be competing for time with your main thread, which is
calling WaitNextEvent, which takes a larger fraction of a second each time
it is called. In addition, if the user holds the mouse button down over a menu
or a control, WaitNextEvent won't get called until the user lets go, which
can be a _long_ time.
- -------- Here is what I do
pre-allocate resources, and make a "freelist" of them using the Enqueue()
system call.
>From my completion routine, I grab resources with Dequeue(). Enqueue()
and Dequeue() are specifically safe to call at interrupt time. The system
checks the state of the keyboard and mouse at interrupt time, and Dequeues()
an EventRecord from a low-memory linked list of free event records, fills
it in, and Enqueues() it on the event queue. I use a similar technique,
with a private event queue, that I poll at WaitNextEvent time, to see if
the interrupt driven side of my program has any messages for the user
interface side of the program.
My completion routines generally start more async i/o, but they also start
up "deadman" VBL tasks, which if the VBL fires, KillIO()s the async i/o
and enters an error recovery in the completion routine state machine. If the
i/o completes first, the i/o completion routine disables the VBL.
No race condition is possible, since if the i/o has completed, the KillIO
will do nothing, but if the KillIO comes in before the i/o is complete, the
i/o will be cancelled.
I'm the only guy in the world with
o a Logitech Cyberman x,y,z,roll,pitch,yaw joysitck,
o a Kurta serial tablet,
o an X-10 CP290 Home Control interface
on my mac, all running off of my own drivers.
--
- ------- <mail-to:oster@netcom.com> ----------
There is no sight finer than that of the planet Earth in your rearview mirror.
---------------------------
>From mdg@seas.gwu.edu (Mark D. Gerl)
Subject: Distinguishing QT-compressed PICTs
Date: 24 Feb 1995 05:19:23 GMT
Organization: George Washington University
Here is my question: Without requiring the presence of QT, how do I
determine that a particular PICT file IS QT compressed (so I can skip it
if QT is NOT installed)? In other words, how do I distinguish a valid
1-bit B&W pict from a QT-compressed one?
Thanks!
Mark
- --------------------------------------------------------------------------
Mark D. Gerl | "The key to immortality is first living a life worth
mdg@seas.gwu.edu | remembering" - Brandon Bruce Lee
- --------------------------------------------------------------------------
+++++++++++++++++++++++++++
>From sardaukar@aol.com (Sardaukar)
Date: 24 Feb 1995 22:22:21 -0500
Organization: America Online, Inc. (1-800-827-6364)
>Here is my question: Without requiring the presence of QT, how do I
>determine that a particular PICT file IS QT compressed (so I can skip it
>if QT is NOT installed)? In other words, how do I distinguish a valid
>1-bit B&W pict from a QT-compressed one?
Straight from d e v e l o p:
The key to your question is "sit in the bottlenecks." If the picture
contains any QuickTime-compressed images, the images will need to pass
through the StdPix bottleneck. This is a new graphics routine introduced
with QuickTime. Unlike standard QuickDraw images, which only call StdBits,
QuickTime-compressed images need to be decompressed first in the StdPix
routine. Then QuickDraw uses StdBits to render the decompressed image. So
swap out theQuickDraw bottlenecks and put some code in the StdPix routine.
If it's called when you call DrawPicture, you know you have a compressed
picture. To determine the type of compression, you can access the image
description using GetCompressedPixMapInfo. The cType field of the
ImageDescription record will give you the codec type. See the
CollectPictColors snippet on this issue's CD and "Inside QuickTime and
Component-Based Managers" in develop Issue 13, specifically pages 46 and
47, for more information on swapping out the bottlenecks.
---------------------------
>From jbeeghly@u.washington.edu (Jeff Beeghly)
Subject: Getting TEHandle from dialog item number
Date: 25 Feb 1995 21:26:09 GMT
Organization: University of Washington
I have a dialog that contains several TextEdit items. The items were
created in ResEdit, not on the fly by calling TENew.
My problem: In the dialog filter I'm writing, I need to be able to
access several of the TE fields (I need to Activate & DeActivate).
I can't just use SelIText & GetIText because I need the TEHandle of a
particular field.
Right now I can access the CURRENT TE field by using
((DialogPeek )theDialog)->textH, but this only applies to the current field.
Ideally, I'd like to find (or create) a call that does
theTEHndl = TEHFromDialogNumber(theDialog, theNumber);
where theTEHndl is a TEHandle, theDialog is a DialogPtr, and theNumber is
a short (it's the item number).
I have THINK Ref, and I've read through the TextEdit, Dialog Manager, and
Control manager sections. The stuff in the TextEdit section all seem to
require a TEHandle of the item in question, but since I am not creating
the TE fields on the fly, I don't have the TEHandles. My goal: Find out
how to get a TEHandle from a dialog index number.
Any help would be EXTREEMLY helpful at this point....
Thanks in advance,
Jeff
+++++++++++++++++++++++++++
>From Matt Slot <fprefect@umich.edu>
Date: 25 Feb 1995 23:52:02 GMT
Organization: University of Michigan
Jeff Beeghly, jbeeghly@u.washington.edu writes:
> My problem: In the dialog filter I'm writing, I need to be able to
> access several of the TE fields (I need to Activate & DeActivate).
There are 2 ways to write dialogs, with ModalDialog() or a modeless dialog
(this includes movable modal for most intents/purposes) using
DialogSelect().
ModalDialog offers a filterProc for you to intercept events, but you can
always return FALSE to let the Dialog Mgr handle it -- but Modal Dialogs
should only need to be activated once! You are not supposed to switch out
of them when they are up.
If you have a modeless dialog, then it may need to be
activated/deactivated
several times across its lifetime. However, DialogSelect() should already
handle (and eat) the activate events. Note that you dont write a filter
function for DialogSelect... you handle it through your main event loop.
> I can't just use SelIText & GetIText because I need the TEHandle of a
> particular field.
>
> Right now I can access the CURRENT TE field by using
> ((DialogPeek )theDialog)->textH, but this only applies to the current
field.
>
> Ideally, I'd like to find (or create) a call that does
>
> theTEHndl = TEHFromDialogNumber(theDialog, theNumber);
>
> where theTEHndl is a TEHandle, theDialog is a DialogPtr, and theNumber
is
> a short (it's the item number).
Each Dialog has only 1 TERec allocated for it because you are only
supposed
to have one active text field in a window. When the user tabs between
items
or clicks in a new text field, the Dialog Mgr resets the ((DialogPeek)
theDialog)->textH field to be a text record for the new active field.
Because there is little need to modify the TERec of inactive items, there
is
little way to do this beyond the GetIText(), SetIText(), and SelIText()
functions
provided. If you *need* to, you can twiddle the given TERec, but I have
done
lotsa custom dialog stuff and never needed to.
> I have THINK Ref, and I've read through the TextEdit, Dialog Manager,
and
> Control manager sections. The stuff in the TextEdit section all seem
to
> require a TEHandle of the item in question, but since I am not
creating
> the TE fields on the fly, I don't have the TEHandles. My goal: Find
out
> how to get a TEHandle from a dialog index number.
Unfortunately TR is not much help, cuz the information is scattered in
bit and
pieces. You might try NIM-Mac Toolbox Essentials... it is a total rewrite
of the
necessary information.
Matt
+++++++++++++++++++++++++++
>From altura@aol.com (ALTURA)
Date: 25 Feb 1995 21:43:34 -0500
Organization: America Online, Inc. (1-800-827-6364)
> My goal: Find out
> how to get a TEHandle from a dialog index number.
The Dialog Manager only creates one TEHandle for the entire dialog. When
an edit text item is activated, the Dialog Manager munges the TEHandle for
the dialog to use that item's data. The item_h returned by GetDItem for
each edit text item is merely a handle with text that the Dialog Manager
puts in the TEHandle's hText field.
-Jordan
+++++++++++++++++++++++++++
>From jbeeghly@u.washington.edu (Jeff Beeghly)
Date: 27 Feb 1995 00:32:50 GMT
Organization: University of Washington
Matt Slot <fprefect@umich.edu> writes:
>There are 2 ways to write dialogs, with ModalDialog() or a modeless dialog
>(this includes movable modal for most intents/purposes) using
>DialogSelect().
>ModalDialog offers a filterProc for you to intercept events, but you can
>always return FALSE to let the Dialog Mgr handle it -- but Modal Dialogs
>should only need to be activated once! You are not supposed to switch out
>of them when they are up.
>If you have a modeless dialog, then it may need to be
>activated/deactivated
>several times across its lifetime. However, DialogSelect() should already
>handle (and eat) the activate events. Note that you dont write a filter
>function for DialogSelect... you handle it through your main event loop.
I am using a custom filter proc, however, the reason I want to activate &
de-activate TE items is that I'm creating dialogs that act like the
standard "Save file" dialog box.
In a dialog box I'm working on, there are two lists boxes and two TE
fields. Pressing TAB switches the focus. In my dialog box, it goes TE1,
TE2, ListBox1, ListBox2. When LB1 or LB2 have the focus, a rectangle
outlines the list box (please see NIM, More Toolbox Essentials: List
Boxes for further info), and I need to de-select the current TE field.
+++++++++++++++++++++++++++
>From Matt Slot <fprefect@umich.edu>
Date: 27 Feb 1995 00:49:18 GMT
Organization: University of Michigan
Jeff Beeghly, jbeeghly@u.washington.edu writes:
> I am using a custom filter proc, however, the reason I want to
activate &
> de-activate TE items is that I'm creating dialogs that act like the
> standard "Save file" dialog box.
You should only have to deactivate and then activate the current text
field,
which is accessible thru the textH field of the DialogPeek (the other
field
is already deactivated).
Or, you might try to see if you can tweak the textH and editField info
directly, and use it to indicate the current keyboard focus for both
text AND and lists. (My impression is that the Dialog Mgr wont like this,
but it may be worth a shot.)
---------------------------
>From Martin Cowley <cowley@sys.uea.ac.uk>
Subject: How to get a CLUT from a PICT file?
Date: 20 Feb 1995 19:32:46 GMT
Organization: BITE Project, UEA
I'm putting the finishing touches to a hypermedia system in C++ on Mac
and Windows that uses QuickTime and QuickTime for Windows. It uses the
QuickTime DisplayPictureFromFile() function to display the picture
straight from disk, rather than reading it into memory first (which is
something I still haven't found a straightforward way of doing). It sets
up the picture's frame from the information supplied by the
GetPictureFileHeader() function.
All my picture files have the same CLUT (optimised with Debabelizer), and
I'd like to be able to set up the CLUT from the PICT file too without
having to read the whole thing into memory first. Does anyone know of a
good way to do this? At the moment I'm storing the CLUT as a resource,
but this means that I have to recompile every time my CLUT changes, and
also that I need to store every possible CLUT as a resource. Reading the
CLUT from the file would make the system far more flexible as it would be
able to deal with new CLUTs without modification.
QuickTime for Windows has a GetPicturePalette() function which extracts
the palette from a memory-resident PICT, but then QTW also has a
GetPictureFromFile() function which sets up a picture in memory from the
disk file. If it's not possible to get the CLUT from the file on a Mac
then I guess I'll have to read it in first, but how? The Mac seems to
have no equivalent to QTW's GetPictureFromFile() function, and the only
relevant bit of code I've seen is in the Apple PICT File Format Notes -
it looks pretty horrendous and assumes you want to draw the picture as
you're reading it, which is not what I want to do.
Any help on this would be very much appreciated!
Thanks in advance,
Martin.
____________________________________________
Martin Cowley
Senior Research Associate
BITE Project
UEA Norwich
NR4 7TJ
UK
Email: cowley@sys.uea.ac.uk
URL : http://www.sys.uea.ac.uk/acc/photos/cowley.html
+++++++++++++++++++++++++++
>From english@primenet.com (Lawson English)
Date: 24 Feb 1995 01:18:22 GMT
Organization: Primenet
Martin Cowley (cowley@sys.uea.ac.uk) wrote:
: I'm putting the finishing touches to a hypermedia system in C++ on Mac
: and Windows that uses QuickTime and QuickTime for Windows. It uses the
: QuickTime DisplayPictureFromFile() function to display the picture
[snipt]
: QuickTime for Windows has a GetPicturePalette() function which extracts
: the palette from a memory-resident PICT, but then QTW also has a
: GetPictureFromFile() function which sets up a picture in memory from the
: disk file. If it's not possible to get the CLUT from the file on a Mac
: then I guess I'll have to read it in first, but how? The Mac seems to
: have no equivalent to QTW's GetPictureFromFile() function, and the only
: relevant bit of code I've seen is in the Apple PICT File Format Notes -
: it looks pretty horrendous and assumes you want to draw the picture as
: you're reading it, which is not what I want to do.
What you are looking for is in NIM:Imaging with QUickDraw, pp 7-13&14.
Assuming that you've gotten a file reference number for the PICT file:
+++++++++++++++++++++++++++
Drawing a Picture Stored in a 'PICT' File
Listing 7-2 illustrates an application-defined routine, called
MyDrawFilePicture, that uses File Manager routines to retrieve a picture
saved in a 'PICT' file. The MyDrawFilePicture routine takes a file
reference number as a parameter.
Listing 7-2 Opening and drawing a picture from disk
FUNCTION MyDrawFilePicture(pictFileRefNum: Integer; destRect: Rect): OSErr;
CONST
cPicFileHeaderSize = 512;
VAR
myPic: PicHandle;
dataLength: LongInt;
err: OSErr;
BEGIN {This listing assumes the current graphics port is set.}
err := GetEOF(pictFileRefNum,dataLength); {get file length}
IF err = noErr THEN BEGIN
err := SetFPos(pictFileRefNum,fsFromStart,
cPicFileHeaderSize); {move past the 512-byte 'PICT' }
{ file header}
dataLength := dataLength - cPicFileHeaderSize;
{remove 512-byte }
{ 'PICT' file header from file length}
myPic := PicHandle(NewHandle(dataLength)); {allocate picture handle}
IF (err = noErr) & (myPic <> NIL) THEN BEGIN
HLock(Handle(myPic)); {lock picture handle before using FSRead}
err := FSRead(pictFileRefNum,dataLength,Ptr(myPic^)); {read file}
HUnlock(Handle(myPic)); {unlock picture handle after using FSRead}
MyAdjustDestRect(myPic,destRect); {see Listing 7-7 on page 7-18}
DrawPicture(myPic,destRect);
IF QDError <> noErr THEN
; {likely error is that there is insufficient memory}
KillPicture(myPic);
END;
END;
MyDrawFilePicture := err;
END;
In code not shown in Listing 7-2, this application uses the File Manager
procedure StandardGetFile to display a dialog box that asks the user for
the name of a 'PICT' file; using the file system specification record
returned by StandardGetFile, the application calls the File Manager
function FSpOpenDF to return a file reference number for the file. The
application then passes this file reference number to MyDrawFilePicture.
Because every 'PICT' file contains a 512-byte header for application-
specific use, MyDrawFilePicture uses the File Manager function SetFPos
to skip past this header information. The MyDrawFilePicture function then
uses the File Manager function FSRead to read the file's remaining
bytes -those of the Picture record- into memory.
The MyDrawFilePicture function creates a handle for the buffer into which
the Picture record is read. Passing this handle to the DrawPicture
procedure, MyDrawFilePicture is able to replay onscreen the commands
stored in the Picture record.
For large 'PICT' files, it is useful to spool the picture data from disk as
necessary instead of reading all of it directly into memory.
+++++++++++++++++++++++++++++++++++++++++++++
Once you have the PICT file in memory, you can use the GetPictInfo
function to gather info about a single picture:
(NIM:Imaging, pp 7-47&48)
++++++++++++++++++++++++++++++++++++++++
GetPictInfo
Use the GetPictInfo function to gather information about a single picture.
FUNCTION GetPictInfo (thePictHandle: PicHandle;
VAR thePictInfo: PictInfo; verb: Integer;
colorsRequested: Integer;
colorPickMethod: Integer;
version: Integer): OSErr;
thePictHandle: A handle to a picture.
thePictInfo: A pointer to a PictInfo record, which will hold information
about the picture. The PictInfo record is described on page 7-32.
verb A value indicating what type of information you want GetPictInfo to
return in the PictInfo record. You can use any or all of the following
constants or the sum of the integers they represent:
CONST
returnColorTable = 1; {return a ColorTable record}
returnPalette = 2; {return a Palette record}
recordComments = 4; {return comment information}
recordFontInfo = 8; {return font information}
suppressBlackAndWhite
= 16; {don't include black and }
{ white with returned colors}
++++++++++++++++++++++
For more info, look at NIM:Imaging, chapter 7.
Hope that this helps...
--
- -----------------------------------------------------------------------------
Lawson English __ __ ____ ___ ___ ____
english@primenet.com /__)/__) / / / / /_ /\ / /_ /
/ / \ / / / / /__ / \/ /___ /
- -----------------------------------------------------------------------------
---------------------------
>From TICS28@waccvm.corp.mot.com (Alan Long)
Subject: I need gWorlds??
Date: 22 Feb 1995 06:14:10 MST
Organization: Motorola
I'm new to Mac programming, and found during development of my first
(simple!) application that updating the screen after being revealed from
behind another window is a real pain. It's difficult to keep track of
what should be on-screen and what should not, at any point in time, so my
screen update function became almost as complicated as the rest of the
program.
Is the answer to use the famous gWorlds (I haven't yet crossed
swords with these)? I get the feeling that it is preferable to always
write to an off-screen gWorld and then use CopyBits to write to my
visible screen. A screen update can then presumably be accomplished by
simply copying from off-screen.
Is this the best general solution to my updating problem?
Regards,
Alan
+++++++++++++++++++++++++++
>From Gordon Graber <gg4921s@acad.drake.edu>
Date: 22 Feb 1995 14:51:57 GMT
Organization: Drake University
In article <1995Feb22.132656.21397@schbbs.mot.com> Alan Long,
TICS28@waccvm.corp.mot.com writes:
>behind another window is a real pain. It's difficult to keep track of
>what should be on-screen and what should not, at any point in time, so my
>screen update function became almost as complicated as the rest of the
>program.
Perhaps you, like I, are making the the situation too complicated. I
have found that the easiest way the update a window is to draw the entire
window. When issuing your drawing calls, bracket them with
the BeginUpdate/EndUpdate statements. This will allow the system to
handle exactly what part of the window actually gets drawn into.
You need not be concerned with what part of a window is, say, revealed,
because the update mechinism handles that for you
GWorlds are not going to help you in this respect. What gworlds will
allow you to do is set up your window, offscreen. When you copy the
offscreen gworld to your window, your window is drawn
"at once", without the user seeing all the drawing calls executing that
comprise the graphics inside your window. Since you have constucted the
"content" of your window offscreen, and then copy that offscreen
"content" to your "visible" window, the user only sees one "drawing
command".
Again it is the update mechanism that ensures that only the parts of
the window that need updating, i.e. the parts that have been uncovered,
are actually drawn into.
Hope it helps!
Gordon Graber: gg4921s@acad.drake.edu
+++++++++++++++++++++++++++
>From ssample1@cc.swarthmore.edu (Stephen &roo Sample)
Date: Wed, 22 Feb 1995 12:34:05 -0500