From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-110 C.S.M.P. Digest Sat, 16 Sep 95 Volume 3 : Issue 110 Today's Topics: Control action procedures Errors in PowerPC section of Mac Game Gurus book Implementing tear off menus? Where do I begin? KillPicture or DisposeHandle? New release of Chipmunk Basic TransSkel 3.22 is available (Thread Manager support added) [Q] How do I write a Photoshop plug-in? 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 newsgroups comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for people who read news semi-regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail 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 ug930175@omega.scs.carleton.ca (Mark Suska) Subject: Control action procedures Date: Wed, 30 Aug 1995 01:50:21 GMT Organization: Carleton University I am trying to get an action procedure for the scrollbar indicator to work. I have no problems getting the action procedures to work for other controls or other regions of the scrollbar. I know that the action procedure for indicators takes no parameters unlike the action procedures for other areas which take two parameters, the control handle and the part code. Right now the action procedure is called correctly the first time but the application exits immediately after returning from it. I've traced it with a debugger and can it seems to crash in the system code wich called my action procedure. Is there something special that you have to do in this action procedure? I don't return anything from the procedure, should I? Any suggestions as to what I am doing wrong? Thanks for your help. -- Mark Suska, ug930175@omega.scs.carleton.ca +++++++++++++++++++++++++++ >From Francois-Regis.Degott@imag.fr (F. Degott) Date: 30 Aug 1995 12:08:20 GMT Organization: LMC-IMAG Grenoble France In article , ug930175@omega.scs.carleton.ca (Mark Suska) wrote: >I am trying to get an action procedure for the scrollbar indicator to >work. I have no problems getting the action procedures to work for other >controls or other regions of the scrollbar. I know that the action >procedure for indicators takes no parameters unlike the action procedures >for other areas which take two parameters, the control handle and the part >code. >Right now the action procedure is called correctly the first time but the >application exits immediately after returning from it. >I've traced it with a debugger and can it seems to crash in the system >code wich called my action procedure. >Is there something special that you have to do in this action procedure? I >don't return anything from the procedure, should I? >Any suggestions as to what I am doing wrong? > Hi Mark, see the IM extract of Dialog Manager below, about TrackControl proc. it seems that the ActionProc must have two differents headers according to the type of control. FUNCTION TrackControl (theControl: ControlHandle; startPt: Point; actionProc: ProcPtr) : INTEGER; [...] TrackControl may take additional actions beyond highlighting the control or dragging the indicator, depending on the value passed in the actionProc parameter, as described below. Here you'll learn what to pass for the standard control types; for a custom control, what you pass will depend on how the control is defined. - If actionProc is NIL, TrackControl performs no additional actions. This is appropriate for simple buttons, check boxes, radio buttons, and the thumb of a scroll bar. - ActionProc may be a pointer to an action procedure that defines some action to be performed repeatedly for as long as the user holds down the mouse button. (See below for details) - If actionProc is POINTER(-1), TrackControl looks in the control record for a pointer to the control's default action procedure. If that field of the control record contains a procedure pointer, TrackControl uses the action procedure it points to; if the field contains POINTER(-1), TrackControl calls the control definition function to perform the necessary action. (If the field contains NIL, TrackControl does nothing.) The action procedure in the control definition function is described in the section "Defining Your Own Controls". The following paragraphs describe only the action procedure whose pointer is passed in the actionProc parameter or stored in the control record. If the mouse button was pressed in an indicator, the action procedure (if any) should have no parameters. This procedure must allow for the fact that the mouse may not be inside the original control part. If the mouse button was pressed in a control part other than an indicator, the action procedure should be of the form PROCEDURE MyAction (theControl: ControlHandle; partCode: INTEGER); In this case, TrackControl passes the control handle and the part code to the action procedure. (It passes Ø in the partCode parameter if the mouse has moved outside the original control part.) As an example of this type of action procedure, consider what should happen when the mouse button is pressed in a scroll arrow or paging region in a scroll bar. For these cases, your action procedure should examine the part code to determine exactly where the mouse button was pressed, scroll up or down a line or page as appropriate, and call SetCtlValue to change the control's setting and redraw the thumb. (warning) Since it has a different number of parameters depending on whether the mouse button was pressed in an indicator or elsewhere, the action procedure you pass to TrackControl (or whose pointer you store in the control record) can be set up for only one case or the other. If you store a pointer to a default action procedure in a control record, be sure it will be used only when appropriate for that type of action procedure. The only way to specify actions in response to all mouse-down events in a control, regardless of whether they're in an indicator, is via the control definition function. Hope this helps. Fr - ----------------------------------------------------------------------- FR Degott (Francois-Regis.Degott@imag.fr) Lab. LMC-IMAG - UJF - Grenoble - France - ----------------------------------------------------------------------- +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Wed, 30 Aug 1995 18:01:11 -0700 Organization: SPC In article , ug930175@omega.scs.carleton.ca (Mark Suska) wrote: >I am trying to get an action procedure for the scrollbar indicator to >work. I have no problems getting the action procedures to work for other >controls or other regions of the scrollbar. I know that the action >procedure for indicators takes no parameters unlike the action procedures >for other areas which take two parameters, the control handle and the part >code. I posted a replacement for TrackControl that handles clicks in the thumb portion of the correctly (and uses the normal TrackControl for parts that it handles correctly). If you can't find it, leave me mail and I'll send it to you. +++++++++++++++++++++++++++ >From ari@shore.net (Ari Halberstadt) Date: Thu, 31 Aug 1995 22:49:26 -0400 Organization: North Shore Access/Eco Software, Inc; (info@shore.net) In article , Francois-Regis.Degott@imag.fr (F. Degott) wrote: >In article , >ug930175@omega.scs.carleton.ca (Mark Suska) wrote: > >>I am trying to get an action procedure for the scrollbar indicator to >>work. I have no problems getting the action procedures to work for other >... >see the IM extract of Dialog Manager below, about TrackControl proc. >it seems that the ActionProc must have two differents headers >according to the type of control. I use the following code to avoid this split-personality aspect of TrackControl. Anything with "ws" calls to my libs. /* function passed to wsCtlTrack */ typedef void (*wstControlTrack)(wstControl ctl, wstInteger part, void *data); /* data needed by mouse tracking call-back function */ typedef struct { wstControlTrack proc; wstControl ctl; wstInteger part; void *data; } ControlTrackStructure; /* global for access from action and indicator callbacks */ static ControlTrackStructure *gTrack; /* function passed to TrackControl for clicks in parts other than indicators */ static pascal void CtlTrackAction(ControlHandle macctl, short part) { #pragma unused (macctl) ControlTrackStructure *track = gTrack; ws_check(wsCtlValid(track->ctl)); ws_check(track->proc != NULL); track->proc(track->ctl, part, track->data); } /* function passed to TrackControl for clicks in indicators */ static pascal void CtlTrackIndicator(void) { ControlTrackStructure *track = gTrack; ws_check(wsCtlValid(track->ctl)); ws_check(track->proc != NULL); track->proc(track->ctl, track->part, track->data); } /* ŸwsCtlTrack tracks the mouse in the control. The 'proc' parameter may be a pointer to a function to call while the mouse is held down, or it may be (ControlProcType)-1L, or NULL. The 'data' parameter is passed to the function pointed to be the 'proc' parameter, and may contain any application defined data. A control part code is returned if the mouse is released in an active part of the control, otherwise zero is returned. See the description of the Toolbox routine TrackControl for more details. */ wstInteger wsCtlTrack(wstControl ctl, const wssPoint *where, wstControlTrack proc, void *data) { static ControlActionUPP uppCtlTrackAction; /* UPP for action function */ static DragGrayRgnUPP uppCtlTrackIndicator; /* UPP for action function */ ControlTrackStructure track; /* information for action function */ ControlHandle dummy; /* dummy parameter for FindControl */ wstBoolean indicator; /* true if clicked in indicator */ wssQDPoint qdpt; /* point that was clicked */ wstInteger part; /* part that was clicked */ wssPortState state; /* saved state of port */ ws_require(wsCtlValid(ctl)); if (! uppCtlTrackAction) { uppCtlTrackAction = NewControlActionProc(CtlTrackAction); wsThrowIfNull(uppCtlTrackAction); } if (! uppCtlTrackIndicator) { /* see comment in , it says to use a DragGrayRgnUPP */ uppCtlTrackIndicator = NewDragGrayRgnProc(CtlTrackIndicator); wsThrowIfNull(uppCtlTrackIndicator); } if (wsCtlStyle(ctl) == wskCtlStylePopupMenu) { /* it's a popup menu, so adjust the menus before it's selected */ wsEventMenuAdjust(); } wsPointToQDPoint(where, &qdpt); wsGPortSetup(wsPanePort(ctl->pane), &state); if (proc != NULL && proc != (wstControlTrack) -1L) { part = FindControl(qdpt, GetControlOwner(ctl->macctl), &dummy); indicator = (part > 128); track.ctl = ctl; track.data = data; track.proc = proc; track.part = part; ws_check(! gTrack); gTrack = &track; if (indicator) part = TrackControl(ctl->macctl, qdpt, (ControlActionUPP) uppCtlTrackIndicator); else part = TrackControl(ctl->macctl, qdpt, uppCtlTrackAction); gTrack = NULL; } else part = TrackControl(ctl->macctl, qdpt, (ControlActionUPP) proc); wsGPortRestore(wsPanePort(ctl->pane), &state); return(part); } Here's a little bonus :-) /*---------------------------------------------------------------------------*/ /* Definitions for Strict Controls (until Apple provides them) */ /*---------------------------------------------------------------------------*/ #define ControlIsVisible(ctl) (((**(ctl)).contrlVis) != 0) #define GetControlHilite(ctl) ((**(ctl)).contrlHilite) #define GetControlData(ctl) ((**(ctl)).contrlData) #define GetControlRect(ctl, r) ((void) ((*r) = (**(ctl)).contrlRect)) #define GetControlOwner(ctl) ((**(ctl)).contrlOwner) #define GetControlProc(ctl) ((**(ctl)).contrlDefProc) -- Ari Halberstadt (ari@shore.net) --------------------------- >From english@primenet.com (Lawson English) Subject: Errors in PowerPC section of Mac Game Gurus book Date: 2 Sep 1995 10:09:36 GMT Organization: Primenet (602)395-1010 Well, I was all excited when I picked up _Tricks of the Mac Game Programming Gurus_. Overall, it does look like a nice book. However, there are some rather BAD errors in the chapter on PowerPC optimization. There are errors of fact (e.g. "low-end PowerPC's have 5 instructional units that can work simultaneously and complete up to three instructions per cycle") and errors in interpreting timing information. The chapter applies this misinterpretation to optimizing a full-screen blit without even providing an optimized CopyBits version as a benchmark, and thereby hangs the tale... The author of the chapter asserts that double floating point stores take 3 cycles to complete. This is *best* case and doesn't apply when all loads and stores are done using the same floating point register in a massively-unrolled loop. The author is excited by the fact that one can get a 3% increase in speed by unrolling the blitting loop so that a full scanline is blitted per iteration of the loop (i.e. 80 in-line instructions). No attempt at pipelining by using multiple registers is discussed or attempted. No mention of any possible assembly-level optimizations (e.g. touching the cache) is made. No discussion of the branch prediction unit and how that effects unrolling of loops is made. No discussion of how the slow speed of the VRAM video bus justifies using the slower double load/store-based blitting instead of the the theoretically faster integer load/store. The author also somehow misreads the timing of the double load and assumes that it is identical to the double store, and that one can simply add instructions' cycle times to calculate the time it takes to execute a given instruction stream. Nor is any discussion made of how these issues might change with the 604 CPU. Nor is any discussion made of how to determine whether a video card with accelerated blitting might be faster, so that Apple's CopyBits (which transparently uses hardware-based blitters, as I recall) might be the better bet. Since the author never times CopyBits, we can't even see how his/her "optimized" version does against Apple's own. I suspect that Apple's generic blitter can do better than the author's hand "optimized" one. I'm the first to admit that I don't understand the PowerPC optimization issues all that well, but the author appears (to my limited understanding) to be even more clueless than I. Disappointing, to say the least. Hopefully the rest of the book is more fact-full... -- - ----------------------------------------------------------------------------- Lawson English __ __ ____ ___ ___ ____ english@primenet.com /__)/__) / / / / /_ /\ / /_ / / / \ / / / / /__ / \/ /___ / - ----------------------------------------------------------------------------- --------------------------- >From "Stephen E. Maas" Subject: Implementing tear off menus? Where do I begin? Date: Mon, 28 Aug 1995 19:13:29 GMT Organization: Maasware Enterprises Where do I start looking for information implementing global tear off menus? Was there a tech. note written on the subject? Are there any files or code examples out there documenting how it is done? I am not asking for help yet, just a nudge in the proper direction. Thanks. +++++++++++++++++++++++++++ >From samny@nyc.pipeline.com (Ed Samuels) Date: 29 Aug 1995 00:43:31 -0400 Organization: The Pipeline In article , Stephen E. Maas writes: >Organization: Maasware Enterprises >Mime-Version: 1.0 >Date: Mon, 28 Aug 1995 19:13:29 GMT >X-Mailer: Mozilla 1.1N (Macintosh; I; 68K) >X-Url: news:comp.sys.mac.programmer.help >Lines: 7 > >Where do I start looking for information implementing global tear off >menus? Was there a tech. note written on the subject? Are there any >files or code examples out there documenting how it is done? I am not >asking for help yet, just a nudge in the proper direction. Thanks. > > > > I'd recommend creating your own MDEF, a menu definition procedure, instead of that complicated custom-font thing that Hypercard and the TCL use. Divide the menu up into rectangles with pictures in them (with something like an 'nrct' resource) and track as the user moves the mouse over those rectangles. When the user tracks outside of the menu + a certain border, start dragging the tear-off around, and finish by posting an apple event to your application to move the tear-off palette to that location. For info about writing MDEFs, look at the New Inside Mac:Mac Toolbox Essentials, page 3-87. - --------------------------------------------------------------------------------------------------- Richard Samuels samny@nyc.pipeline.com +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Tue, 29 Aug 1995 14:21:47 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Stephen E. Maas (do485@cwru.edu) wrote: : Where do I start looking for information implementing global tear off : menus? Was there a tech. note written on the subject? Are there any : files or code examples out there documenting how it is done? I am not : asking for help yet, just a nudge in the proper direction. Thanks. ftp ftp.info.apple.com, the DTS.Draw source, for one. Also, Nigel Perry's "Pictoid" source has something similar (don't know if it tears off). There's an init or control panel that implements global tear-offs already. "Why code it if somebody already wrote it" is a time and trouble saving maxim. -Ken- --------------------------- >From altitude@petrified.cic.net (Alex Tang) Subject: KillPicture or DisposeHandle? Date: 31 Aug 1995 16:28:03 GMT Organization: University of Michigan sorry if this is a newbie question.... When drawing picts using: hPict = PicHandle ( NewHandle ( nDataLength ) ); FSRead ( nFileRef, &nCount, ( Ptr ) *hPict ); HLock ( ( Handle ) hPict ); DrawPicture ( hPict, &rectPict ); HUnLock ( ( Handle ) hPict ); should i use DisposeHandle() or KillPicture() to finish up. Thanx. ...alex... +++++++++++++++++++++++++++ >From andrewwelc@aol.com (AndrewWelc) Date: 31 Aug 1995 13:22:16 -0400 Organization: America Online, Inc. (1-800-827-6364) > should i use DisposeHandle() or KillPicture() to finish up. Either -- KillPicture just calls DisposeHandle() anyway (and does nothing else). Regards, Andrew Welch Thaumaturgist Ambrosia Software, Inc. .......... For the latest versions of our software, technical support, and Ambrosia news, stop by and visit the Ambrosia Software, Inc. support forums: America Online ---> Keyword: Ambrosia CompuServe ---> GO word: Ambrosia eWorld --> Shortcut: Ambrosia >From altitude@petrified.cic.net (Alex Tang) --------------------------- >From Ron Nicholson Subject: New release of Chipmunk Basic Date: 29 Aug 1995 01:12:05 GMT Organization: Silicon Graphics, Inc. I'm not sure how many c.s.m.p folks still consider writing stuff in the BASIC language as a form of programming... But, in case you're still one of the few, there's a new release of Chipmunk Basic, vers. 3.2.1. It's a bug fix release with a few minor enhancements. Already in the Info-Mac archives and also here: Looks like Chipmunk Basic may soon be obsoleted by the rumored "Kenobi" and "Danali" implementations. - - Ronald H. Nicholson, Jr. rhn@engr.sgi.com, rhn@netcom.com #include // I speak only for myself, etc. --------------------------- >From dubois@night.primate.wisc.edu (Paul DuBois) Subject: TransSkel 3.22 is available (Thread Manager support added) Date: 1 Sep 1995 12:10:41 -0500 Organization: UW-Madison Primate Center Release 3.22 of TransSkel, a skeleton for Macintosh application development under MetroWerks C or Pascal or Symantec C++/THINK C, is now available. This is an update release; it provides Thread Manager support. It also fixes a bug so that the TransSkel library correctly knows the application is suspended when launched directly into the background. Thread Manager support and the bugfix were both contributed by Hans van der Meer, hansm@fwi.uva.nl. My thanks to him. TransSkel is available via any of the following: anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel) gopher to gopher.primate.wisc.edu, then select "Primate Center Software Archives") WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/ -- Paul DuBois dubois@primate.wisc.edu Home page: http://www.primate.wisc.edu/homepage/dubois Software: http://www.primate.wisc.edu/software --------------------------- >From bmw@ccnet.com (Brett M. Wayne) Subject: [Q] How do I write a Photoshop plug-in? Date: 30 Aug 1995 16:40:17 GMT Organization: Initial Point Software I am working on a ground station support package for a spacecraft that has as part or its sensor suite, several imaging sensors. The ground station is being developed on a Silicon Graphics workstation so I'm not at a loss for compute cycles. My current path to getting processed imagery into finished documents is to translate the raw imagery into some standard format (i.e. TIFF, GIF, etc. ) before I pull them into Photoshop. The main problem with this is that I lose all of the non-pixel meta-data in the translation. It would be neat if I could write a simple Photoshop plug-in that would enable me to import/export the images in their native, definitely non-standard format. I'm not a newbie to Mac programming. I've programmed using both Codewarrier, and Symmantec C++/TCL, Resedit, Resorcerer, etc. If anyone has had experience doing this, I'd greatly appreciate pointers to references, additional tools required, etc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Brett M. Wayne University of California Lawrence Livermore National Laboratory wayne1@llnl.gov +++++++++++++++++++++++++++ >From kemper@ucssun1.sdsu.edu (kemper) Date: 31 Aug 1995 04:37:36 GMT Organization: San Diego State University Computing Services Adobe's plugin architecture for Photoshop is on the the CW CD. You can also join their developer's program for more info, or buy one of their special CD thingies =). Brett M. Wayne (bmw@ccnet.com) wrote: : I am working on a ground station support package for a spacecraft that : has as part or its sensor suite, several imaging sensors. The ground : station : is being developed on a Silicon Graphics workstation so I'm not at a loss : for compute cycles. : My current path to getting processed imagery into finished documents is to : translate the raw imagery into some standard format (i.e. TIFF, GIF, etc. ) : before I pull them into Photoshop. The main problem with this is that I : lose : all of the non-pixel meta-data in the translation. It would be neat : if I could write a simple Photoshop plug-in that would enable me to : import/export the images in their native, definitely non-standard format. : I'm not a newbie to Mac programming. I've programmed using both : Codewarrier, : and Symmantec C++/TCL, Resedit, Resorcerer, etc. If anyone has had : experience : doing this, I'd greatly appreciate pointers to references, additional tools : required, etc. : -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= : Brett M. Wayne : University of California : Lawrence Livermore National Laboratory : wayne1@llnl.gov +++++++++++++++++++++++++++ >From phixus@deltanet.com (Chris De Salvo) Date: Thu, 31 Aug 1995 01:15:42 -0700 Organization: MacPlay In article , bmw@ccnet.com (Brett M. Wayne) wrote: > before I pull them into Photoshop. The main problem with this is that I > lose > all of the non-pixel meta-data in the translation. It would be neat > if I could write a simple Photoshop plug-in that would enable me to > import/export the images in their native, definitely non-standard format. At any of the Info-Mac mirros you can find the Photoshop Developers Kit. It includes sample source for import and export plug-ins. In the Info-Mac hierarchy it is at: _Development _Library photoshop-kit.hqx> Good luck, Chris -- +-----------------------------------------------------------------+ | phixus@deltanet.com | Macintosh: Changing the world, | | Chris De Salvo | one person at a time! | | Professional Mac Geek | ----------------------------- | | for MacPlay, Inc. | (I wish they'd hurry up!) | +-----------------------------------------------------------------+ Any opinions expressed, or implied, are my own! They should not be considered representative of the opinions or policies of my employer, MacPlay, a division of Interplay Productions, Inc. +++++++++++++++++++++++++++ >From Darren Giles Date: Thu, 31 Aug 1995 08:21:29 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Adobe has a SDK for Photoshop plug-ins. Believe it or not, it's already on the CodeWarrior CD. You could also check their WWW site (http://www.adobe.com/), or give 'em a call. Best of luck! - Darren ========================================================================== Darren Giles, Technical Director mars@netcom.com Terran Interactive http://www.terran-int.com --------------------------- End of C.S.M.P. Digest **********************