APPLE II Q & A

APPLE II DEVELOPER TECHNICAL SUPPORT

Q How can I "dim" text in my Apple II GS application, similar to the way the Toolbox dims menu titles and menu options, and the way that HiliteControl dims a button name?

A Dimming text is a piece of cake. Here's how the Apple II GS Menu Manager does it in both 640 and 320 mode. The same thing works great for both.

1. Calculate the bounding box of the text.
2. Fill it with the proper background color for the operation in question.
3. Draw the text.
4. Execute code that looks something like this:

    pea dimmed>>16
    pea dimmed
    _SetPenMask         ;Set the pen mask to "dimmed" mask
    pea textRect>>16
    pea textRect        ;Push pointer to text boundary rect
    lda backColor       ;Get text's background color
    and #$00FF          ;Always solid

; Here you need to do something in your code to get the 
; appropriate pattern for the text you're drawing. This will be 
; one of the 16 patterns in the 512-byte table, starting with 16 
; bytes of $00, 16 bytes of $11, and ending with 16 bytes of $FF.
; We leave the routine GetColorPtr for you to code, but our 
; example assumes it returns the pointer we need in A (low word) 
; and X (high word).

    jsr GetColorPtr         ;(see above)
    phx                     ;high word
    pha                     ;low word
    _FillRect               ;Fill will be dithered
    pea nor_mask>>16  ;Reset drawing mask to normal solid
    pea nor_mask
    _SetPenMask
    rts

textRect    DC.B $00,00,00,00   ;Put your rectangle here
backColor   DC.W $0000          ;Background color of text to dim

dimmed      DC.B $55,$AA,$55,$AA,$55,$AA,$55,$AA
nor_mask    DC.B $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF

Yes, it's really this easy!

Q When I call FixFontMenu from my Apple II GS new desk accessory (NDA), everything works fine, but if the current application has a font menu it stops working. What's wrong?

A FixFontMenu keeps only one correspondence between menu item IDs and font family numbers--if you call FixFontMenu from an NDA, you blow away the already existing correspondence that the application was using, maintained within the Font Manager. ItemID2FamNum then works only on item IDs corresponding to your NDA's font menu, and these usually are unrelated to the values the application passes from its font menu. Worse, FamNum2ItemID will subsequently return menu item IDs for font family numbers that have nothing to do with the application's menus; depending on how the application operates on the resulting item ID, this could be disastrous.

Fortunately, doing this yourself is fairly easy with the Font Manager's help. CountFamilies tells you how many font families there are, and FindFamily returns the name of each of them. You can manipulate this information into a font menu in a fairly straightforward way, using standard Menu Manager calls. While you're at it, you can also use FindFontStats to figure out what point sizes and styles are available for each font family, so you can indicate this in your Size and Style menus. You could even use the information to build your own font-choosing dialog, much as HyperCard IIGS does. Remember that your NDA should run in either 320 or 640 mode, so don't make the dialog box too wide.

Q When using an Apple II GS run queue item, can I use the second reserved field to find out when the item was last executed? I assume this value is the tickCount. Currently, I just get the current tickCount and subtract the last tickCount. Using this field could save me one tool call, and when doing animation via a RunQ, every extra tick counts.

A No, you should not use undocumented fields in the run queue header because they could change with future software releases. However, there is a fast way to get the current tick count. Pass refNum $0005 to the GetAddr function in the Miscellaneous Tools once each time your program runs, and it tells you the location of the tick counter. Since the tick count changes during heartbeat interrupts, be sure to disable interrupts around your direct accesses to the tick counter (PHP, SEI, access tick count, PLP).

If your application makes certain tool calls frequently, it may be worthwhile to short-circuit the tool dispatcher and transfer control to the Toolbox function directly (if the tool takes a long time to execute anyway, it isn't worth it). You can get a function's address and work area pointer by calling GetFuncPtr and GetWAP in the Tool Locator. When the function gets control, the Y and A registers must contain the tool set's work area pointer, the X register must contain the function number, and there must be two RTL addresses on the stack.

Q Does the Apple IIe Card for the Macintosh LC have a technical reference manual?

A There's no separate technical reference manual. Use the Apple IIe Technical Reference (Addison- Wesley), together with Apple IIe Technical Note #10, "The Apple IIe Card for the Macintosh LC."

Q What's the proper method of saving the Apple II GS Super Hi-Res (SHR) screens? If my application both uses shadowing and is fast-port aware, the restored screen colors are garbaged. Can I simply use HandToPtr with ptr representing the screen addresses, or will this mess up the scan-line control byte (SCB) restoration since these are read-modify-write locations?

A The shadowed screen's SCBs may not be correct, so by saving and restoring them you're causing random data to be restored into the standard SCBs. Your best bet, if shadowing is on, is to turn shadowing off, restore the bank $01 screen, including its SCBs and color tables, turn shadowing on, and restore the $E1 screen and contents. If you don't want to double-restore the $E1 screen and $01 screen, you should turn shadowing off, restore the bank $01 color tables/SCBs, turn shadowing on, and restore the $01 screen. But, since these screens are never guaranteed to be the same when you save, you should always restore both screens separately.

QuickDraw never touches the shadowed screen SCBs, so if the fastPort flag is set you can ignore the restoring of the bank $01 SCBs/color tables, since the application promised not to interfere with them. But since this won't save very much time, you probably shouldn't worry about it.

Q I am using an Apple II GS utility to generate resources for my application, and I noticed that some of the resource IDs generated are in the range $07FF0000 to $07FFFFFF, which is reserved for the system software's use. What's happening?

A Your utility is calling UniqueResourceID with an IDRange of $FFFF, to request any unused resource ID. A bug in system software version 5.0.x allows UniqueResourceID to accidentally return a system-range resource ID if any system-range resources of that type are already present. This will be fixed in System 6. In the meantime, utilities can use UniqueResourceID with IDRange values other than $FFFF, and you should watch your resource IDs carefully to avoid using system-range resource IDs.

Kudos to our readers who care enough to ask us terrific and well thought-out questions. The answers are supplied by our teams of technical gurus; our thanks to all. Special thanks to Matt Deatherage, Jim Luther, Dave Lyons, Jim Mensch, and Eric Soldan for the material in this Q & A column. *

Have more questions? Need more answers? Take a look at the Dev Tech Answers library on AppleLink (updated weekly) or at the Q & A stack on the Developer CD Series disc.*