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 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 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. -- - ------- ---------- 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 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 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 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 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 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 Organization: RadioÖcular Stereo Systems In article <3ifj2d$ad3@dunix.drake.edu>, Gordon Graber wrote: > 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 The other thing you can do is use the visRgn of the window (window->visRgn) as the mask region when you update with CopyBits. This is probably marginally faster than the method described above (fewer calls and less memory being thrown around), but I don't have any numbers. Ta, -Stephen +++++++++++++++++++++++++++ >From blm@chinook.halcyon.com (Brian L. Matthews) Date: 22 Feb 1995 17:58:10 GMT Organization: NW NEXUS, Inc. -- Internet Made Easy (206) 455-3505 In article <1995Feb22.133656.21633@schbbs.mot.com>, Alan Long wrote: |Is this [GWorlds] the best general solution to my updating problem? Without knowing more about your application it's hard to say, but in general, the answer is probably not. First, you only need to keep track of what's in the window, because BeginUpdate will cause your drawing to be clipped to the region of your window that needs updating. In fact, you could draw all your data, and Quickdraw will automatically clip things correctly. Of course if you've got a lot of things to draw, trap overhead may kill you, so you could compare each item's bounds to the clip region yourself. Second, keeping GWorlds may take a *lot* of memory. Consider a full color window on a 1024x768, 16bit screen. If the window is zoomed to full size, a GWorld would probably be around 960x750x2 or 1.44Meg. And a 1024x768 screen isn't the biggest available, and with multiple monitors your window could be much bigger. And of course that's just one window, if you support multiple windows (which, in general, you should), you'll need a GWorld for each. Pretty soon your memory requirements will exceed even those of Microsoft apps. :-) Before resorting to GWorlds, look at the design of your app and how you keep track of your data. Some judicious redesign may solve your problem. Brian -- Brian L. Matthews blm@halcyon.com You can't have a syntax error with a hammer. +++++++++++++++++++++++++++ >From Gordon Graber Date: 22 Feb 1995 19:05:04 GMT Organization: Drake University In article Stephen &roo Sample, ssample1@cc.swarthmore.edu writes: >The other thing you can do is use the visRgn of the window >(window->visRgn) as the mask region when you update with CopyBits. This is >probably marginally faster than the method described above (fewer calls >and less memory being thrown around), but I don't have any numbers. Isn't this the region that the system uses through the update mechanism, anyway? Or are you helping the system out, in a sense, by setting this region manually? Can you elaborate? Thanks, Gordon Graber: gg4921s@acad.drake.edu +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 22 Feb 1995 13:08:32 -0800 Organization: Internet for the Olympic Peninsula In article <1995Feb22.133656.21633@schbbs.mot.com>, TICS28@waccvm.corp.mot.com (Alan Long) wrote: > 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. gWorlds aside, the general paradigm is to do ALL drawing in response to update events ("live" scrolling in its various forms being a key exception). That means your app needs to keep track of what should be drawn where (which is fairly natural: if it were to read the same data >From a file it would have to know what should be drawn where). Then upon update, the easy way is to draw everything. Slightly more complex (and perhaps lots faster) is to draw only things which intersect the area of the window being drawn. And using gWorlds is a little more complex, but in many ways better (the user doesn't see things being drawn--she sees the result). > 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? Often, yes. Not always. Suggest you study the code samples (unfortunately, that means the more complex ones). --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] Isn't C fun? jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 24 Feb 1995 19:31:29 +1300 (NZDT) Organization: (none) TICS28@waccvm.corp.mot.com (Alan Long) writes: > 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? The general solution is to maintain some sort of data structure that describes the screen contents, and have a single Draw() function that draws the whole mess (or better: just the contents of a rectangular area. This should usually be the *only* place in your program that you draw the contents of your window. Anywhere else that you really think you want to change what's on the screen, you should just call InvalidRect() on the area you want to draw into, and wait for the system to send you an update event. This breaks down for things like feedback on mouse tracking, and other animation, but is a good general rule, to br broken when needed. Now, the data structure that you create to describe the screen's contents will usually be something like a list of the objects on the screen, but in some cases you might in fact want to have this data structure be an off-screen GWorld. The reason for doing this would usually be that redrawing the screen takes too long otherwise, and not because it is too complicated. If you can draw it in the first place then it's usually not too much harder to do it so you draw it on demand. Of course, something that is very complicated to draw is probably also slow to draw. But we're talking *really* complicated -- like a 3D render of a complex scene -- before that's an issue. Bear in mind also that an offscreen GWorld can solve the window revealing problem, but it doesn't solve the window resize problem, or the window scrolling problem unless the offscreen GWorld is the size of the entire document, not just the size of the window. A Draw() routine that can on demand draw any rectangle from your document, OTOH, solves all these problems, and that is exactly how application frameworks such as MacApp and TCL and PowerPlant do window revealing and resizing and scrolling (and printing, too). All by calling a single user-supplied Draw() routine to draw an appropriate rectangle. Hope this helps. -- Bruce --------------------------- >From giampaol@snowhite.eeap.cwru.edu (Jude Giampaolo) Subject: IP --> Name translation Date: Sun, 26 Feb 1995 12:33:57 -0500 Organization: CWRU Amoeba Project I'm looking for a code example that takes an IP address and returns the hostname. I would prefer Pascal, but C would be ok too. Thanks.... -- Jude Giampaolo Case Western Reserve University Electrical Engineering 'There's not much to see actually, and Applied Physics we're inside a Chinese dragon...' jcg8@po.cwru.edu giampaol@snowhite.eeap.cwru.edu +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (chris-b) Date: Mon, 27 Feb 1995 18:37:58 +1200 Organization: HyperMedia Unit, Comp Sci, Auckland University In article , giampaol@snowhite.eeap.cwru.edu (Jude Giampaolo) wrote: >I'm looking for a code example that takes an IP address and returns the >hostname. I would prefer Pascal, but C would be ok too. Here's some C to do the job. Read "MacTCP Programmer's Guide" for more info. Most error handling is removed for clarity. #include OSErr Err; ip_addr IPAddr; SInt16 IOResult; hostInfo HInfo; //////////////////////////////////////// //Get IP address IPAddr = ??; //////////////////////////////////////// //Open DNR Err = OpenResolver(nil); if (Err != noErr) { } //////////////////////////////////////// //Lookup our machine name on net IOResult = inProgress; Err = AddrToName(IPAddr,&HInfo,(ResultProcPtr)DNRResultProc,(char*)&IOResult); if (Err == cacheFault) { WaitFor(&IOResult); Err = HInfo.rtnCode; } switch (Err) { case noErr: //Machine name (CString) in HInfo.cname break; case noNameServer: case authNameErr: case noAnsErr: case dnrErr: case outOfMemory: Err = CloseResolver(); break; default: Err = CloseResolver(); break; } //////////////////////////////////////// //Close DNR Err = CloseResolver(); if (Err != noErr) { } //////////////////////////////////////// Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- --------------------------- >From berntson@oeb.harvard.edu (Glenn M. Berntson) Subject: LDEFs - HOW? Date: Mon, 20 Feb 1995 08:50:51 -0400 Organization: Harvard University I've been playing with lists for a while and have heard mention of LDEFs to add functionality to lists. How do they work? Where can I find informtion on how to create and use an LDEF? Any information would be greatly appreciated. Thanks Glenn +++++++++++++++++++++++++++ >From Matt Slot Date: 20 Feb 1995 16:29:08 GMT Organization: University of Michigan Glenn M. Berntson, berntson@oeb.harvard.edu writes: > Where can I find informtion on how to create and use an LDEF? Look at your local Sumex mirror for a file called "sample-ldefs", somewhere in the depths of the "dev" directory. Matt +++++++++++++++++++++++++++ >From kurisuto@babel.ling.upenn.edu (Sean Crist) Date: 20 Feb 1995 22:41:14 GMT Organization: University of Pennsylvania, Linguistics Department In article , Glenn M. Berntson wrote: >I've been playing with lists for a while and have heard mention of LDEFs >to add functionality to lists. > > How do they work? Where can I find informtion on how to create and use > an LDEF? The idea of definition functions is common to several of the Toolbox managers: the menu manager uses MDEFs to draw menus; the window manager uses WDEFs to draw windows; the list manager uses LDEFs to draw cells in lists. For example, the menu manager doesn't do the actual drawing of menus itself; instead, it calls an MDEF at the appropriate time to draw a menu. There's the standard MDEF that draws normal text menus, but you can write your own MDEF for, say, a tools menu or a patterns menu. Likewise with the List Manager. The List Manager figures out how which cell you've clicked in, what the scroll bars should be doing, etc, but the actual drawing of the cells is done by the LDEF. The standard LDEF draws strings, but you can write an LDEF to draw any kind of cell you like (lists of icons, etc.) The description in OldIM IV is pretty clear on how to do this (I have no idea where it is in NIM). Apple's original idea was that the LDEF would be a separate resource which would contain all the code to draw a cell, but the problem is that such things are annoying to debug, since you can't use your programming environment to step through them as you can with regular application code. What a lot of people do is just to make a little _stub_ of an LDEF which only contains a machine instruction to jump into your main code; then, you can do your debugging as usual within your program and can also access all of your program's globals from within your pseudo-LDEF, which you can't do >From a real LDEF (Usual caveats about self-modifying code apply). If you want details on how to do this, write me, or I can post some Pascal code if there's interest. \/ __ __ _\_ --Sean Crist (kurisuto@unagi.cis.upenn.edu) --- | | \ / For a free copy of the Bill of Rights, finger _| ,| ,| ----- this account. _| ,| ,| [_] Q: What do Standard Oil, AT&T, and Microsoft have in | | | [_] common? A: Nothing... yet. +++++++++++++++++++++++++++ >From cwatson@cam.org (Chris Watson) Date: Wed, 22 Feb 1995 16:23:27 -0500 Organization: Communications Accessibles Montreal, Quebec Canada In article , berntson@oeb.harvard.edu (Glenn M. Berntson) wrote: > I've been playing with lists for a while and have heard mention of LDEFs > to add functionality to lists. > > How do they work? Where can I find informtion on how to create and use an LDEF? > > Any information would be greatly appreciated. An LDEF is a List Definition, it's just a little piece of code that controls how items in a list of drawn, and highlighted... For example, standard file uses a custom LDEF so those icons can be drawn next to the file name. You can get info in NIM:More Mac ToolBox, in the List Manager section... .:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::. | Chris Watson | | cwatson@cam.org Hooked on foniks werkes four me! | | Montreal, Canada | i:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::i --------------------------- >From Carl R. Osterwald Subject: ShowDragHilite -- a real drag? Date: Wed, 15 Feb 1995 16:16:53 GMT Organization: National Renewable Energy Laboratory The HIG for the drag manager states that a window which will be the drop location of a drag should be highlighted when the mouse is inside that window. To that end, ShowDragHilite is provided to perform this function. Unfortunately, it only seems to work when the region to be highlighted is mostly white (such as Finder windows), or if the bit depth is 1 (in which case it inverts pixels). If graphics are displayed in the region to be highlighted (such as when a pix map is being displayed), ShowDragHilite does nothing. This behaviour does not seem to be documented in the programmer's guide. Also, if scrolling is to take place, one is supposed to call DragPreScroll and DragPostScroll so that the highlighting can be erased before scrolling takes place, and then restored afterwards. It has been my experience that these routines may be buggy in that in certain scrolling situations, the highlighting is not erased properly and you end up with a series of bars running across your nice clean window. This seems to happen about 5% of the time. The only solution I can see is to dedicate a 3-pixel border around the outside the display portion of the window for drag highlighting (inside of the scroll bars, of course). Doing this also gets around the scrolling problem because the highlighting never has to be erased. In summary, it would seem that the drag manager was designed and optimized for the Finder and displays of text, not graphics. Any comments? +++++++++++++++++++++++++++ >From blm@coho.halcyon.com (Brian L. Matthews) Date: 16 Feb 1995 08:20:00 GMT Organization: NW NEXUS, Inc. -- Internet Made Easy (206) 455-3505 In article , Carl R. Osterwald wrote: |Unfortunately, it [ShowDragHilite] only seems to work when the region to be |highlighted is mostly white (such as Finder windows), or if the bit |depth is 1 (in which case it inverts pixels). It actually works, it just doesn't look that way. :-) ShowDragHilite sets hilite mode and inverts the region. This means that in a multi-bit environment, any pixel that is the background color (white, unless you've changed it) is replaced with the hilite color (normally set via the Color control panel). So if your window is completely filled with non-white (or non-background color) pixels, ShowDragHilite will appear to do nothing. |Also, if scrolling is to take place, one is supposed to call |DragPreScroll and DragPostScroll so that the highlighting can be erased |before scrolling takes place, and then restored afterwards. It has |been my experience that these routines may be buggy in that in certain |scrolling situations They use updateRgn so if you're doing something strange with it, or not calling BeginUpdate/EndUpdate or ScrollRect in the normal fashion, it may not work. I've never seen a problem with it though. |The only solution I can see is to dedicate a 3-pixel border around the |outside the display portion of the window for drag highlighting (inside |of the scroll bars, of course). Doing this also gets around the |scrolling problem because the highlighting never has to be erased. Or you could overwrite the outer 3 pixels with the diagonal stripes pattern or draw in the hilight color directly (instead of just inverting in the hilite mode). If your window can contain any colors, then it will always be possible to construct a graphic that is unchanged by any hiliting in the window itself. Hmm, just had a thought. Maybe you could use a set of diagonal patterns to make a "marching ants" hilighting. I believe the Drag and Drop HIG mentions "marching ants" marquees for when a simple 50% gray pattern outline might not be distinguishable from the stuff in the window, so it would make sense to use a similar thing when ShowDrawHilite hilighting might not be distinguishable from the contents of the window. I'll have to remember that. :-) |In summary, it would seem that the drag manager was designed and |optimized for the Finder and displays of text, not graphics. |Any comments? ShowDragHilite and friends provide a simple way to get the standard behavior when your window contains some stuff over the background color, which is pretty common. If you have something different, you may not be able to use the drag manager provided routines for scrolling and highlighting. Think of ShowDragHilite and friends as helper functions that provide the "90%" behavior. If you need the "10%" behavior, you have all of Quickdraw to fall back on. Brian -- Brian L. Matthews blm@halcyon.com You can't have a syntax error with a hammer. +++++++++++++++++++++++++++ >From Malcolm Pradhan Date: 16 Feb 1995 17:09:18 GMT Organization: Section on Medical Informatics, Stanford University In article Carl R. Osterwald, carl_osterwald@nrel.gov writes: >Also, if scrolling is to take place, one is supposed to call >DragPreScroll and DragPostScroll so that the highlighting can be erased >before scrolling takes place, and then restored afterwards. It has >been my experience that these routines may be buggy in that in certain >scrolling situations, the highlighting is not erased properly and you >end up with a series of bars running across your nice clean window. >This seems to happen about 5% of the time I also thought this was the case when I was getting all sorts of junk thanks to these calls. I was even more suspicious when I discovered that the Finder doesn't use these calls, it erases the DragHilite and redraws it each time. Unusually ugly for the Finder. However, after I finished my app I have not had this trouble. It seems that the DragPre/PostScroll are easily confused, for example during debugging. I'm not convinced that these are buggy in normal use but they aren't reliable during development. Regards, Malcolm +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Thu, 16 Feb 1995 16:22:46 GMT Organization: National Renewable Energy Laboratory In article <3hv1rg$blj@news1.halcyon.com> Brian L. Matthews, blm@coho.halcyon.com writes: >They use updateRgn so if you're doing something strange with it, or not >calling BeginUpdate/EndUpdate or ScrollRect in the normal fashion, it >may not work. I've never seen a problem with it though. This is probably what I am seeing--I do have to monkey with the updateRgn. >Or you could overwrite the outer 3 pixels with the diagonal stripes >pattern or draw in the hilight color directly (instead of just >inverting in the hilite mode). If your window can contain any colors, >then it will always be possible to construct a graphic that is >unchanged by any hiliting in the window itself. ShowDragHilite uses only a 2 pixel outline, so I just inset the graphic display area by this amount. The appearance of a 2 pixel border around the content is barely noticeable, plus it avoids the scrolling problem, so I chose this solution. Also, the time/memory it would take to redraw window portions obliterated by the highlighting would be unacceptable in my case. >Hmm, just had a thought. Maybe you could use a set of diagonal >patterns to make a "marching ants" hilighting. I believe the Drag and >Drop HIG mentions "marching ants" marquees for when a simple 50% gray >pattern outline might not be distinguishable from the stuff in the >window, so it would make sense to use a similar thing when >ShowDrawHilite hilighting might not be distinguishable from the >contents of the window. I'll have to remember that. :-) Because I already have a marching ants border, the pattern was still (accidently) set to this pattern when I called ShowDragHilite, so I saw an effect similar to this. I didn't like it because it is very different from what one sees in the Finder. >|In summary, it would seem that the drag manager was designed and >|optimized for the Finder and displays of text, not graphics. >|Any comments? > >ShowDragHilite and friends provide a simple way to get the standard >behavior when your window contains some stuff over the background >color, which is pretty common. If you have something different, you >may not be able to use the drag manager provided routines for >scrolling and highlighting. Think of ShowDragHilite and friends as helper functions that provide the "90%" behavior. If you need the >"10%" behavior, you have all of Quickdraw to fall back on. I agree. +++++++++++++++++++++++++++ >From blm@coho.halcyon.com (Brian L. Matthews) Date: 17 Feb 1995 18:35:43 GMT Organization: NW NEXUS, Inc. -- Internet Made Easy (206) 455-3505 In article , Carl R. Osterwald wrote: |ShowDragHilite uses only a 2 pixel outline, so I just inset the graphic |display area by this amount. |Because I already have a marching ants border, the pattern was still |(accidently) set to this pattern when I called ShowDragHilite, so I saw |an effect similar to this. I didn't like it because it is very |different from what one sees in the Finder. Although I haven't tried it, this would be my concern too, that it's different enough that it might not be obvious that it means the same as the highlight color border. I agree that the 2 pixel border is the way to go. As a bonus, it probably helps set off the graphic from the window even when the window isn't drag hilited. Brian -- Brian L. Matthews blm@halcyon.com You can't have a syntax error with a hammer. +++++++++++++++++++++++++++ >From devans@apple.com (Dave Evans) Date: 23 Feb 1995 09:45:22 GMT Organization: Apple Computer, Inc. > > ... To that end, ShowDragHilite is provided to perform this > >function. Unfortunately, it only seems to work when the region to be > >highlighted is mostly white ... > > > >Also, if scrolling is to take place, one is supposed to call > >DragPreScroll and DragPostScroll so that the highlighting can be erased > >before scrolling takes place, and then restored afterwards. It has > >been my experience that these routines may be buggy ... Hello, Let me answer some comments about the DragHilite routines in the Drag Manager toolbox. First, the general rule for drag hilites is to provide the best feedback for your users. You may need to customize the Drag and Drop Guidelines to fit your interface, and in some cases the DragHilite routines may not meet your needs. Specifically, the ShowDragHilite routine will only work correctly if the window's background color is white or a very light gray. On a darker gray background, I recommend you draw our own drag hilite in a very dark grey and restore to your background color manually. This should be easy to implement. The DragPreScroll and DragPostScroll routines should work fine. Be careful with your port's clip region -- if you modify this during your scroll the drag scroll routines might leave bits behind. For best scroll appearance, however, I recommend using an offscreen port for your drawing -- just use the show and hide hilite routines in this port -- then update to the screen for flicker free scrolling. And the reason the Finder doesn't use the DragPreScroll and DragPostScroll routines is because: 1. They don't use offscreen drawing (probably to use minimal memory) 2. The Drag Manager and Finder version 7.1.x were developed concurrently 3. and Francis, the fabulous Finder Engineer, promised he was going to use them but never got around to adding them before finishing the Finder... everyone in unison now: "bad Francis..." Thank You, Dave Evans not a Finder engineer - -- Apple Computer, Inc. pays the bills but doesn't necessarily endorse what I put in writing. (especially after 1 am) --------------------------- End of C.S.M.P. Digest **********************