• MacTech Network:
  • Tech Support
  • |
  • MacForge.net
  • |
  • Apple News
  • |
  • Register Domains
  • |
  • SSL Certificates
  • |
  • iPod Deals
  • |
  • Mac Deals
  • |
  • Mac Book Shelf

MAC TECH

  • Home
  • Magazine
    • About MacTech in Print
    • Issue Table of Contents
    • Subscribe
    • Risk Free Sample
    • Back Issues
    • MacTech DVD
  • Archives
    • MacTech Print Archives
    • MacMod
    • MacTutor
    • FrameWorks
    • develop
  • Forums
  • News
    • MacTech News
    • MacTech Blog
    • MacTech Reviews and KoolTools
    • Whitepapers, Screencasts, Videos and Books
    • News Scanner
    • Rumors Scanner
    • Documentation Scanner
    • Submit News or PR
    • MacTech News List
  • Store
  • Apple Expo
    • by Category
    • by Company
    • by Product
  • Job Board
  • Editorial
    • Submit News or PR
    • Writer's Kit
    • Editorial Staff
    • Editorial Calendar
  • Advertising
    • Benefits of MacTech
    • Mechanicals and Submission
    • Dates and Deadlines
    • Submit Apple Expo Entry
  • User
    • Register for Ongoing Raffles
    • Register new user
    • Edit User Settings
    • Logout
  • Contact
    • Customer Service
    • Webmaster Feedback
    • Submit News or PR
    • Suggest an article
  • Connect Tools
    • MacTech Live Podcast
    • RSS Feeds
    • Twitter

ADVERTISEMENT
Volume Number:5
Issue Number:8
Column Tag:TechNotes

Related Info: Control Manager

New CDEF Messages

By James Plamondon, Berkeley, CA

System 7.0 will present all Macintosh programmers with new opportunities and new challenges. One of the challenges will be making your code 32-bit clean. This can be particularly difficult if your code uses parts of the Toolbox that are not 32-bit clean. Some of the routines in the Control Manager, for example, are at best only 31-bit clean -- that’s close, but not close enough for System 7.0. This article will answer the challenge by explaining both the problem with, and the solution to, the Control Manager’s unclean habits.

The specific problem that this article addresses lies in the calcCRgns CDEF message sent to all CDEFs. The message is sent to a control’s CDEF to calculate the control’s enclosing region, or the enclosing region of its indicator (if any). In Inside Macintosh [IM v1 p330], the calcCRgns CDEF message is explained as follows: “Param is a QuickDraw region handle . If the high-order bit of param is set, the region requested is that of the control’s indicator rather than the control as a whole. The definition function should clear the high byte (not just the high bit) of the region handle before attempting to update the region.”

You can see that it’s pretty hard to be 32-bit clean when you’re supposed to go around clearing bytes in handles. The handle could contain a perfectly valid 32-bit address; clearing the high byte would change the address to something entirely different -- and accessing or changing anything via that address would be a terrible mistake. Yet, it is required by the Control Manager, so what is a programmer to do?

First, one can at least improve the situation by not clearing the whole high byte, as directed. Instead, just interrogate the high bit to see what region needs to be calculated, and then clear it -- leaving the rest of the bits alone. This makes the code 31-bit clean; that’s not good enough for System 7.0, but it’ll do for the old systems.

For System 7.0, Apple has defined two new CDEF messages: calcCntlRgn (10) and calcThumbRgn (11). Instead of sending a calcCRgns message and having the CDEF figure out whether the system wants the control region or the indicator (thumb) region, the system will figure out which it wants, and send the CDEF the appropriate (new) message. The CDEF can then treat the region handle like a region handle, instead of like a secret message that has to be decoded.

To make sure the world is a happy place, and that backward compatibility is maintained, a CDEF should always implement both the calcCRgns message and the new CDEF messages. That way, whether the CDEF finds itself in use under either System 7.0 or a pre-7.0 system (which is pretty likely for the next year or two), it will respond in the manner the system expects.

There are a couple of related issues. First, a control’s variation code used to be stored in the high byte of the control record’s contrlDefProc field. To get the variation code, the programmer would mask it out of the high byte. This is unclean, since the contrlDefProc field may contain a valid 32-bit address. A new routine, GetCVariant(), was provided a couple of years ago (IM v5 p222) to return the control’s variation code. Be sure to use it.

Also, whenever writing custom CDEFs or/and other DEFs, remember that The Management Reserves the Right to Add New Messages at Any Time. Therefore, be sure that if your DEF receives a message it doesn’t recognize, it just returns what it was given without doing anything (and without blowing up).

Lastly, if you’re going to add any custom messages to your custom DEF, set the new message numbers to constants greater than 128. This gives Apple the freedom it needs to add new messages, without tromping on your custom messages.

That’s about all the discussion this issue will bear. See the revision to Tech Note #212 for the official version of this same information. Below, I have appended the old, unclean calcCRgns implementation, the new and improved 31-bit clean calcCRgns implementation, and a shell CDEF entry-point function that shows how all these messages should be handled. Note that the ‘param’ actual argument is a valid handle to an empty region, so the content of the region indicated by param needs to be changed, not the value of param itself. You couldn’t make any change to param stick anyway, since it’s not a ‘var’ parameter (i.e., the CDEF gets a copy of param’s value, not its address). Also, I’m assuming the existence of some routines, such as MyCalcThumbRgn() and MyCalcCtlRgn(), that are different for each different CDEF, and which are therefore not given here.

I’d like to thank Andrew Shebanow, Larry Tesler, Charlie Oppenheimer, and Steve Goldberg at Apple -- way to go, guys!

(*****************************************************
MyControl: Main entry point.  Call appropriate
 message-handling routine.
*****************************************************)

FUNCTION MyControl(varCode: INTEGER;
 theCntl: ControlHandle;
 message: INTEGER;
 param: LONGINT): LONGINT;

BEGIN
 MyControl := 0;  { default }

 CASE message OF
 drawCntl:
 doDrawCntl(theCntl, varCode, param);
 testCntl:
 MyControl := doTestCntl(theCntl, param);
 initCntl:
 doInitCntl(theCntl, varCode);
 dispCntl:
 doDispCntl(theCntl, varCode);
 autoTrack:
 doAutoTrack(theCntl, varCode, param);

 calcCRgns: { support for pre-7.0 }
 doCalcCRgnsNew(theCntl, param);
 calcCntlRgn:  { new in System 7.0 }
 MyCalcCtlRgn(theCntl, RgnHandle(param));
 calcThumbRgn:{ new in System 7.0 }
 MyCalcThumbRgn(theCntl, RgnHandle(param));

 OTHERWISE
 ; { ignore all other messages }
 END;  { case }
END;  { MyControl }

(*****************************************************
doCalcCRgnsOld: Calculate the region the
 control or its indicator occupies in its
 window.  Old method: Only 24-bit clean
 -- don’t use this method anymore; use 
 doCalcCRgnsNew(), below.
*****************************************************)

PROCEDURE doCalcCRgnsOld(theCntl: ControlHandle;
 param: LONGINT);

BEGIN
 if (param < 0) then  { high bit is sign bit }
 begin
 { clear high BYTE and set thumb rgn }
 param := BitAnd(param, $0FFFFFFF);
 MyCalcThumbRgn(theCntl, RgnHandle(param));
 end
 else
 begin
 { clear high BYTE and set control rgn }
 param := BitAnd(param, $0FFFFFFF);
 MyCalcCtlRgn(theCntl,
 RgnHandle(param));
 end;
END;  { doCalcCRgnsOld }

(*****************************************************
doCalcCRgnsNew: New method: Only 31-bit
 clean, but that’s the best we can do.
*****************************************************)
PROCEDURE doCalcCRgnsNew(theCntl: ControlHandle;
 param: LONGINT);
BEGIN
 if (param < 0) then  { high bit is sign bit }
 begin 
 { clear high BIT and set thumb rgn }
 param := BitAnd(param, $7FFFFFFF);
 MyCalcThumbRgn(theCntl, RgnHandle(param));
 end
 else
 begin
  { clear high BIT and set control’s rgn }
 param := BitAnd(param, $7FFFFFFF);
 MyCalcCtlRgn(theCntl, RgnHandle(param));
 end;
END;  { doCalcCRgnsNew }

 
MacTech Only Search:
Community Search:

 
 
 

 
 
 
 
 
  • SPREAD THE WORD:
  • Slashdot
  • Digg
  • Del.icio.us
  • Reddit
  • Newsvine
  • Generate a short URL for this page:



MacTech Magazine. www.mactech.com
Toll Free 877-MACTECH, Outside US/Canada: 805-494-9797
MacTech is a registered trademark of Xplain Corporation. Xplain, "The journal of Apple technology", Apple Expo, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, Apple Expo, MacTech Central, MacTech Domains, MacNews, MacForge, and the MacTutorMan are trademarks or service marks of Xplain Corporation. Sprocket is a registered trademark of eSprocket Corporation. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders.
All contents are Copyright 1984-2010 by Xplain Corporation. All rights reserved. Theme designed by Icreon.
 
Nov. 20: Take Control of Syncing Data in Sow Leopard' released
Nov. 19: Cocktail 4.5 (Leopard Edition) released
Nov. 19: macProVideo offers new Cubase tutorials
Nov. 18: S Stardom anounces Safe Capsule, a companion piece for Apple's
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live
Nov. 17: Ableton releases Max for Live