Autumn 91 - A2 Q&A
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.
- Calculate the bounding box of the text.
- Fill it with the proper background color for the operation in question.
- Draw the text.
- 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.*
