|
Volume Number: | 5 | |
Issue Number: | 4 | |
Column Tag: | Assembly Lab |
Related Info: Desk Manager Menu Manager
Icons in DA Menus
By John A. Love, III, Springfield, VA
John got his start in the world of computers a long time ago on main frames while serving in the U. S. Air Force. He has gone from the Apple ][ to the “Fat” Mac to his SE. He can be found on GEnie (J.LOVE7).
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
5100 Poplar Avenue
Suite 2716
Memphis, TN 38137
(901) 683-3383
“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
2151 Brown Avenue
Bensalem, PA. 19020
(215) 639-8764
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
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine