Related Info: Desk Manager Menu Manager

Icons in DA Menus

By John A. Love, III, Springfield, VA

I am currently writing a Desk Accessory in whose MENU Items I would like to have ICONs. Immediately we have two seemingly disparate numbering systems as dictated by “Inside Macintosh” {IM}. The first deals with the arithmetic pertaining to IDs for Resources owned by Desk Accessories; the second pertains to IDs for ICONs placed in MENU Items. Each set of arithmetic is simple enough to understand. The challenge, of course, is their combined implementation in each of two different operational environments.

Let’s quickly review the 1st numbering system pertaining to owned Resources. The best way to accomplish this is the picture contained in Volume I of IM:

Figure 1. Resource ID of an Owned System Resource

Since a Desk Accessory is a DRVR-type Resource, the type bits = 000. The ID of the owning Resource can be derived one of two ways, the most common of which relies on dCtlRefNum in the Device Control Entry (DCE). The last 5 bits, earmarked “variable”, are up for grabs so long, obviously, as the quantity is in the range 0 --> 31. Speaking of ranges, what this long word reduces to is a number in the range = -16000 --> -15521 for a Desk Accessory.

NOW, what about the 2nd numbering system that addresses the IDs of ICONs for MENU Items?? IM stipulates that these numbers be in the range 257 --> 511. Once again it is obvious that when you load or create your MENUs in the Open Section of your DRVR, you’ve got to temporarily change the high negative ID of your owned MENU ICON to a low positive # before you call _SetItmIcon. No sweat, right ?*!!*? Yup, anything you say !!

As if the above gymnastics weren’t enough, it turns out that “Suitcase” searches for the 1st empty slot {a positive Unit # = the ID of the owning Resource} and temporarily converts that to new IDs for your owned Resources. For example, if your Source Code specifies a Unit # of 16 {mandatory range = 12 --> 26}, but “Suitcase” detects an empty Slot #12, “Suitcase” will temporarily change all the IDs of your DA’s owned Resources accordingly {I don’t know what “Font/DA Juggler Plus” does behind the scenes}. Interesting, you say ?*!!*?

Before I address the solution to the above puzzle, I must praise to the skies both the intelligence and patience of the following folk, without whom I would still be groveling:

• Steve Brecher, author of “Suitcase”.

• Dave McWherter, author of

“McAssembly™” {$5000 SW} and the

“McSink” DA. By the way, the latter is now

called “Vantage™” and goes for $8995.

• Dave Smith..

By the way, if I blow it, I hereby declare that I am the sole occupant at the end of this tree limb that I’m busily sawing off. Steve and the two Dave’s are not responsible for any of my mistakes.

First, what does NOT work:

 Open Section   -->  _GetResInfo {original ID}
            
  _SetResInfo {new ID}
 ; ------------------------------

 Close Section -->    _SetResInfo {original ID}

These gyrations won’t work in either operational environment. Oh, your MENU ICONs will show up as advertised after you open your DA in both; however, upon closing the DA, the new ID is still in place {257 -> 511} for the 1st environment [using “Font/DA Mover”]. NO resetting was implemented. As you can see, I do NOT call _WriteResource on closing, because then I would update the System File Resource {YUCK !!} Even if I would be willing to suffer the latter, “Suitcase”, remember, messes with the owned Resource ID and the reset would be back to its make-believe ID, NOT my ID as stored on disk. “Ain’t life wonderful ??”

Okay, folks, how about making a copy of the Handle to your MENU ICONs, and, after doing the appropriate arithmetic, using the copy for your MENU and best of all, this works {well, almost }. All the Source Code that follows uses “McAssembly™”, Version 7.3 :

setMenuIcon MACRO&1,&2,&3 ; MenuHandle,Menu Item #,ICON Name.

 ; First, retrieve the attached ICON Resource:
 move.w RescIDBase,iconID
 addi.w #&2,iconID
 GetIconiconID,=iconHdl
 move.l iconHdl,tempHdl   ; Just temporary, folks !!
 
 ; Then, get the Resource file’s Attributes so we can
 ; reset them later.  After that, we make a copy of the
 ; ICON’s Handle so that we can use the COPY for the MENU:
 
 HomeResFileiconHdl,=resFileRef
 GetResFileAttrs resFileRef,=resFileAttrs
 ; ----------
 move.l iconHdl,a0
 _HandToHand
 move.l a0,cyHdl
 ReleaseResource tempHdl  ; The ORIGINAL Resource.
 ; Now, place the ICON’s COPY in the Menu Item by
 ; changing the ICON’s ID # to between 257 --> 511:
 move.w #&2,iconID
 addi.w #256,iconID
 AddResourcecyHdl,#’ICON’,iconID,!.name
 bra.s  .1
.name   text#&&3
 align
 ; Reset to ORIGINAL Attributes to clear the resChanged
 ; Bit in the Attribute Byte so that we don’t update the
 ; Resource upon Closing AND so “Suitcase” DOES reset to
 ; the disk-based ID:

.1 SetResFileAttrs resFileRef,resFileAttrs
 SetItmIcon &1,#&2,#&2    ; menuHandle,item #,icon #.
 ENDM

Okay, this almost works, but _SetResFileAttrs , itself, will eventually do a _WriteResource. Since close only counts in horseshoes, so much for that idea. Anything else?

What about setting the “MapReadOnly” bit of the Resource file’s Attribute byte so that the changed Resource Map is NOT written to disk. This could be done upon Opening the DA. Upon Closing, the original “MapReadOnly” bit could be reset. Steve Brecher correctly pointed out, however, that this effectively holds your DA’s Resource(s) captive ==> a super big “no-no” !!

Okay, I guess I’ll just have to implement what Dave McWherter suggested several months back write my own Menu Definition Procedure and thank heaven for Darryl Lovato (MacTutor, August 86). Darryl presented his code in Pascal. Just for the sake of converting to assembly, there’s no need to blatantly repeat his code here. However, I do wish to present the sub-Function that handles “mChooseMsg” simply because I have added access to hierarchical menu items that, guess what, also have ICONs. By the way, I use Mike Schuster’s “PopupSelect” routine to implement the hierarchical Menus {see MacTutor, Dec 85}:

Before I present the modified assembly Source code, I would like to extend a 1000 special “Atta-Boys” to Dave McWherter, author of “McAssembly™” and the “Vantage™” DA, aka “McSink”.

Dave’s Assembler, in my considered judgment, incorporates many of the most powerful features of Apple’s “MPW”, while retaining the ultimate of user friendliness. You can even program in the worlds of the 68010, 68020 and 68851 CPUs by invoking a pseudo-opcode, for example, ‘M68020’. A very significant part of this user friendliness focuses on what he calls the “Trap Compiler” with which the assembly language programmer can implement the sometimes-lengthy pushes onto the Stack prior to actually calling the various TRAPs via ONE line of code, just like “LightSpeed Pascal”. At the present time, the current Version (7.3) uses Apple’s “Edit”, or other comparable Editor external to “McAssembly™”. Be forewarned, however -- Dave is working on an update to “McAssembly™” wherein he is incorporating his own Editor internal to his Assembler. In this manner, if there is an assembly error (horrors !!), you bounce automatically into his Editor. Neat, isn’t it, again just like “LightSpeed Pascal”.

So long as I’m advertising, Dave’s “McSink” is now being distributed by :

Preferred Software

“McSink”, now called “Vantage™”, is a text Processing Desk Accessory that includes :

Auto-paste and Auto-copy between multiple windows (max = 16)

Horizontal scrolling

KeyPad control of cursor placement

Catalog Folder contents

Statistics -- # of characters, lines, words, sentences and paragraph in the shown document

Add/Strip prefix & suffix strings, as well as line #s

Dave can be reached via:

Signature Software

Now, onto the Source Code I’ve promised

First, how do I install my own Menu Definition Procedure?? It’s really very easy -- all I do is create a 6--byte handle in which I have code to effect an absolute jump to my Procedure. This Handle is then stored in in the “menuDefHandle” field of the Menu Record. This teeny--tiny code parcel is as follows:

In the Open section of the Desk Accessory Driver:

 move.l #6,d0    ; “jmp  myMenuDefProc”.
 _NewHandle,clear
 move.l a0,myMenuDefHdl
 bra.s  .skipCode
 ; ----------
.code   jmp $CCCCCCCC; 6 bytes.
.absAddrdc.lmyMenuDefProc-.absAddr
 ; ----------
.skipCode move.l (a0),a0  ; Convert to a Pointer.
 lea  .code,a1
 move.w (a1)+,(a0)+; Object Code word for “jmp”.
 lea  .absAddr,a1
 move.l (a1),d1
 lea  (a1,d1.l),a1 ; Absolute address of
 move.l a1,(a0)  ;   “myMenuDefProc”.
  
 NewMenudCtlMenu,!newMenuName,=mainMenuHdl
 AppendMenu mainMenuHdl,!mainMenuItems
 InstallMenuProc mainMenuHdl
  
InstallMenuProc  MACRO  &1; MenuHandle.

 move.l &1,a1    ; Handle -->
 move.l (a1),a1  ;   Pointer.
 move.l myMenuDefHdl,menuDefHandle(a1) ; _NewHandle into Menu Record.
 ; ----------
 CalcMenuSize  &1
 ENDM

Now, the “mChooseMsg” portion of my Menu Definition Procedure as I stated earlier. By the way, you’ll see below some strange looking animals, such as func, endParms, locals, endLocals, enter & exit. These beasts are special Macros that Dave McWherter wrote to assist in the Stack manipulation required to link to an external subroutine.

Some “screwy” things have to happen here in order to simulate a Hierarchical Menu. First, when you choose a main Menu Item that has a Hierarchical {sub} Menu -- you know it’s a Hierarchical Menu Item because its “Cmd-key” = $1B -- you immediately go to an external Popup Menu routine as shown below. Nothing unusual so far But, now you have to fake-out the Menu Manager by returning an un-believably high Item #, like the maximum # = 31, so the Menu Manager does not blink an Item on the main, or parent Menu as you release the Mouse over the subMenu. Hold on, I’m not through yet Down a-ways into the Code, you’ll see a reference to supporting your local _MenuChoice on the Macintosh II. Sure enough, but there’s another equally important reason for placing the Item # in the global, MenuDisable. The reason is that you peg on MenuDisable in the Menu Event section of your Desk Accessory code, instead of on the csParam field of the Parameter Block Record. The reason for this last divet is that otherwise the Menu Manager will not communicate a Menu Event to your DA. Actually, to tell you the truth, this doesn’t make a darn bit of sense, but it’s true when you write your own Menu Definition Procedure instead of using Apple’s !!

Now, hold on a cotton-pickin minute, Love, don’t you know that the new Menu Manger supports Hierarchical Menus already. Yup, sure enough!! However, there’s a bug in the portion of the new Menu Manager that handles screen up-dates after you release the Mouse over a Hierarchical Menu Item {anybody know when System Version 7.0 is due out ??}

; ======================================
; FUNCTION  doChooseMessage (myMenu:MenuHandle; myRect:Rect; myPoint:Point;
;     oldItem:INTEGER) : INTEGER;
; Returns Menu Item # you selected:
doChooseMessage  funcinteger
.myMenu handle
.myRect pointer
.myPointpoint
.oldIteminteger
 endParms
 locals
.oldRectrect
.itemKeychar
.itemMark char
.itemRect rect
 endLocals
.menuHdlrequa1   ; My worker bees ...
.cyParamBlkPtr requa2
.cyDCEPtr requ a3
.menuRegrequa4
.theItemrequd3   ; Counts Items to get current one.
.enableFlagsrequ d4; A disabled
.shift  requd0   ;   item ??
 enter
 
 movem.ld1-d7/a0-a4,-(sp) ; All your goodies.
 ; ==========
 move.l .myMenu,.menuHdl  ; Handle -->
 move.l (.menuHdl),.menuReg ;   Pointer.
 ;
 PtInRect .myPoint,.myRect,=d0
 beq  .outsideMRect
 moveq  #0,.theItem; Initialize counter.
.chooseLoop addq.w #1,.theItem
 push.l .myMenu
 push.l .myRect
 push.w .theItem
 pea  .itemRect
 bsr  GetItemRect
 ; ----------    
 PtInRect .myPoint,!.itemRect,=d1
 beq.s  .chooseLoop
 move.l menuID(.menuReg),d2 ; Support _MenuChoice
 move.w .theItem,d2;   for the Mac II.
 move.l d2,MenuDisable
.disabled?move.l menuEnable(.menuReg),.enableFlags
 BitAnd .enableFlags,#1,=d0 ; Bit #0 for ENTIRE Menu.
 beq.s  .yup; ... it’s disabled.
 ; ----------
 moveq  #1,.shift
 lsl.l  .theItem,.shift   
 BitAnd .enableFlags,.shift,=d1
 bne.s  .deSelectOld
 ; ----------    
.yup    moveq  #0,.theItem; Item is disabled.
.deSelectOldcmp.w.oldItem,.theItem
 beq  .aSelection
 tst.w  .oldItem
 beq.s  .selectNew ; MenuBar, so don’t invert back.
 ; ----------    
 push.l .myMenu
 push.l .myRect
 push.w .oldItem
 pea  .oldRect
 bsr  GetItemRect
 InverRect!.oldRect; Invert back to white
.selectNewtst.w  .theItem
 beq.s  .itsDisabled
 ; ----------    
 InverRect!.itemRect ; Blacken current selection.
 push.l .myMenu
 push.w .theItem
 pea  .itemKey
 bsr  GetItemKey
 cmpi.w #hMenuCmd,.itemKey
 bne.s  .aSelection
 ;
 GetItmMark .myMenu,.theItem,!.itemMark
 GetMHandle .itemMark,=a0 ; = MenuHandle.
 clr.l  -(sp)
 push.l a0
 push.l .myPoint
 bsr  PopupSelect
 pop.l  d1
 tst.w  d1
 beq.s  .onMenuBar ; Item’s disabled.
 move.w #31,.theItem ; ... fake out Menu Manager so it
 ;     doesn’t blink a parent item.
.itsDisabled
.aSelection move.w .theItem,.result
 bra.s  .end
 ; ==========
.outsideMRect  tst.w .oldItem
 beq.s  .onMenuBar
 ; ----------    
 push.l .myMenu
 push.l .myRect
 push.w .oldItem
 pea  .oldRect
 bsr  GetItemRect
 InverRect!.oldRect; Back to white.
.onMenuBarclr.w  .result
 ; ==========
.end    movem.l  (sp)+,d1-d7/a0-a4 ; Withdraw life savings !!
 
 exit