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.
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.*