Letters

Plotting Small Icons

David Dunham

A frequent question on the networks is, “how do you draw small icons (SICNs)?” A quick look at a SICN resource shows it to be simply the bits of the images. SICNs resemble ICN#s in that there can be multiple small icons in the same resource, but there is no count, and no data is presumed to be a mask. Each image is 32 bytes of data. So the SICN with ID=-15744 (in the system file), has the hexadecimal representation:

0000 0000 3FF0 48A8 48A4 4824 47C4 4004 4004 47C4 4824 4824 4824 3FFC 
0000 0000.  (See figure 1)

This is the sort of bit image which CopyBits() manipulates, so drawing the SICN is a simple matter of stuffing the appropriate bit image into a BitMap data structure and calling CopyBits().

/*
PLOTSICN - Draw the sicnNUMth small icon of sicn in  sicnRect of window.
*/
PlotSICN (sicn, sicnRect, sicnNum, window)
Handle sicn; 
Rect *sicnRect; 
short sicnNum;
WindowPtr window;
{
 BitMap sicnBits;

 /* Set up the bit map */
 sicnBits.rowBytes = 2;
 SetRect(&sicnBits.bounds,0,0,16,16);
 sicnBits.baseAddr = *sicn + (sicnNum * 32);
 /* Blit the SICN */
 CoptBits(&sicnBits,&window->portBits, 
 &sicnBits.bounds, sicnRect, srcCopy, NIL);
}

Note that we’re passing a dereferenced handle (*sicn). But according to Professor Mac (Steve Brecher), there’s no need to lock the handle, since CopyBits() won’t alter the heap configuration unless a picture or region is being recorded.

Fig. 1 A Mini-disk icon from the system file

Colorizing Logos

David Dunham

With the advent of the Macintosh II, programs can use color. Doing so effectively and correctly isn’t easy (both technically and from a user interface standpoint). But it’s easy to add a little spice to a program by colorizing the logo in its “about” dialog.

This note assumes that logos are normally PICT items in a dialog, and explains how to make them appear in color on a Macintosh II.

The simplest way to create color logos is to use SuperPaint. Copy a bitmap to the object layer, activate the color palette, and give the bitmap color. If you want to use different colors, you’ll have to use multiple bitmaps. Note that SuperPaint’s color names are misleading. What it calls “orange” displays on the Mac II screen as red. Since you have to run SuperPaint in 1-bit color, the easiest way to see what your graphic really looks like is to copy it into a desk accessory like Acta or Scrapbook and use Control Panel to turn color on.

If you don’t own SuperPaint, you can edit a ‘PICT’ resource with ResEdit. The fgColor opcode is 0E, and it takes a longword of color data (see Tech Note 21).

An advantage of this technique is that you can use it even without owning a Macintosh II. I gave Acta 1.2 a color logo even though it was released before the Macintosh II was introduced. I was able to check my work by printing with an ImageWriter II and a color ribbon. Also, this technique takes no programming, you can color arbitrary shapes, and it’s compatible with all machines. The disadvantage is that you’re limited to the 6 colors (not counting black and white) supported by the original QuickDraw.

If you want to use colors which aren’t black, white, or the additive and subtractive primaries, you’ve got to use Color QuickDraw. But at the time I’m writing this, there are no programs which create Color QuickDraw pictures. (Even if there were, these pictures can’t be used on machines which aren’t running System 4.1 or later. The structure of a version 2 picture prevents it from crashing a machine without ColorQuickDraw or the patches, but also means the picture will come out blank.) And pictures are played back in their original colors-- you can’t use an old ‘PICT’ and just call RGBForeColor and then DrawPicture.

I use a technique similar to the way you dim text-- draw it, then Bic a grey pattern over it. In color, use the new max transfer mode. This replaces the destination color with a color whose individual RGB values are the larger of the source and destination colors’ RGB values. Since the original art is in black, and the dialog backround is white, this simply replaces all black pixels with the color we want (the RGB values for a black pixel are all 0, so our color is used; the RGB values for white are all 65535, so our color is ignored).

There is a catch-- this only works if the dialog is a color window (i.e. has a color grafPort). GetNewDialog creates color windows if there ‘s a ‘dctb’ resource with the same ID as the ‘DLOG’ resource. The easiest way to create a ‘dctb’ it to use ResEdit to copy the one from the Control Panel desk accessory and change its ID.

Note that in a 1-bit deep bitmap, max maps to Bic. Painting in this mode would erase the picture, so we don’t do anything. (I’m assuming that the dialog doesn’t extend over different screens; if it did, the picture could be colorized on one screen and erased on another.)

I used this technique to give Findswell a color logo that matched the logo on the box. The C routine below is the one I used. It’s hardcoded to Findswell’s color, but you could pass the color as an argument.

#define max (37)
#define RGBBlack ((RGBColor *)0xc10)
#define ROM85  (*(int *)0x28e)


/*
COLORIZE -- change the color of an item in a 
 (color) dialog
*/
void colorize(dialog, item) DialogPtr dialog; int item; 
{
 int    type;
 Handle handle;
 GDHandle gh;
 PixMapHandle  pm;
 Rect   box;
 RGBColor   colour;

 If (!(ROM85 & 0x4000)) { /* Mac II ROMs? */
 /* Figure out screen depth of our dialog */
 gh=GetMaxDevice(&((DialogPeek)dialog)-> window.port.portRect);
 pm=(*gh)->gdPMap;  /* Device’s PixMap */
 if ((*pm)->pixelSize > 1) {  /* Enough pixels */
 /* Choose FindSwell’sgolden-brown */
 colour.red=39921;
 colour.green=26421;
 colour.blue=0;
 RGBForeColor(&colour);  /* Set the color */
 PenMode(max);
 GetDItem(dialog, item, &type, &handle, &box);
 PaintRect(&box);  /* Colorize */
 RGBForeColor(RGBBlack);  /* default color */
 PenNormal();  /* Restore default pen */
 }
 }
}

One disadvantage of this technique is that you can see the logo being drawn in black, then painted in brown. The operation is pretty quick, though, and doesn’t require much code.

What if you don’t want to color an entire picture? You can define a userItem, and pass its item number to colorize. This lets you color any rectangular area. To color an arbitrary shape, you can define a bitmap and use CopyMask (CopyMask is not available with 64K ROMs, but we’re not colorizing in that situation). Icons are probably the easiest bitmaps to work with. The routine below will plot the black bits of an icon in the current color; white bits are unchanged.

/*
PAINT_ICON -- Draw transparent icon in current color
 */
void paint_icon(icon, box) Handle icon; Rect *box;
{
 BitMap   iconBits;
 GrafPtr  thePort;

 GetPort(&thePort);  /* Get current grafPort */
 /* Set up the bit map */
 iconBits.rowBytes=4;
 SetRect(&iconBits.bounds, 0,0,32,32);
 iconBits.baseAddr=(char *) (*icon);
 /* Blit the icon */
 CopyMask(&iconBits, &iconBits, &thePort->portBits, &iconBits.bounds, 
&iconBits.bounds, box);
}

ModalDialog Filter Procs from MS FORTRAN

Jeff E. Mandel, MD MS

When writing code in MS FORTRAN, it is occasionally necessary to have a pointer to a piece of code to pass to a toolbox call -- a proc pointer. Absoft has provided a glue routine called ctlprc to perform this function. Ctlprc has a limitation in that it does not return anything on the stack, which is necessary for implementing a filter proc for ModalDialog. An assembly language glue routine for this is described herein.

ModalDialog filter procs are called each time ModalDialog gets an event from GetNextEvent (note that the event mask excludes disk insert and application events). It passes a pointer to the FrontWindow, and two VARs; the EventRecord and the ItemHit. Note that VARs are longword addresses to the data structures, which is exactly how FORTRAN passes calling arguments. ModalDialog expects the filter proc to return a Boolean result; True if ModalDialog should process the event, and False if the filter proc has done so already. A Boolean result should be passed as a word on the stack above the calling arguments, and this is where ModalDialog expects to find it. FORTRAN passes calling arguments as long word addresses, and ctlprc restores the stack on return from the called procedure. Function results are passed register D0, and ctlprc trashes this register. Thus, we must write some assembly code to fix this if we want to write our filter proc in FORTRAN. The following MDS code does just that.

 XDEF xfilt
 INCLUDE MacTraps.D
 INCLUDE SysEqu.D
 INCLUDE ToolEqu.D
 INCLUDE QuickEqu.D

; Xfilt is the initialization code.  It stores the 
; address of the FORTRAN subroutine returned from
; ctlprc and returns a proc pointer which can be 
; passed to ModalDialog.

xFilt:
 MOVEM.LA0-A1,-(SP); Save registers
 MOVE.L 16(SP),A0; calling FORTRAN passes ptr
 LEA  service,A1 ; to filter subroutine
 MOVE.L (A0),(A1); which we store locally

 LEA  action,A0  ; glue procedure address is
 MOVE.L 12(SP),A1; returned to FORTRAN on the
 MOVE.L A0,(A1)  ; stack

 MOVEM.L(SP)+,A0-A1; Registers restored

; Action is the proc which gets called by ModalDialog.
; It massages the stack after FORTRAN finishes with it
; so that a Boolean result can be returned to
; ModalDialog.

action:
 MOVEM.LA1/D0,-(SP); Save registers
 PEA  result; Pass FORTRAN an address to
; store the BOOLEAN result

; Clone the stack
 MOVE.L 24(SP),-(SP) ; Dg_ptr
 MOVE.L 24(SP),-(SP) ;Event record
 MOVE.L 24(SP),-(SP) ; ItemHit

 MOVE.L service, A1; load ptr to FORTRAN
 JSR  (A1); routine and call it

 MOVE.W result,24(SP); get function result and
 ; place on stack where
 ;ModalDialog expects it
 MOVEM.L(SP)+,A1/DO; restore registers

; Fix the stack so that we can RTS
 MOVE.L (SP)+,8(SP); move return address
 ADD.L  #8,SP  ; fix stack pointer
 RTS

; Declare some local storage
service DC.L  0
result  DC.W  0

 end  

The following MDS link file will make a file that the FORTRAN linker can deal with:

; File xfilt.Link

/Data
/Type ‘0000’ ‘0000’

!xfilt

/Output xfilt.sub
[
xfilt

$

Next, we need to set up pointers in the main program:

PROGRAM WHIZ BANG

implicit none
 
integer ctlprc, my_filter, filter_1, my_filter_ptr
external ctlprc, my_filter
 
filter_1=ctlprc(my_filter, 16)   !Four long word 
 ! of arguments
call xfilt(filter_1, my_filter_ptr)

Note that the call to ctlprc should be performed any statements which allocate memory. The FORTRAN filter routine, my_filter should be appended to the main program. This simple filter routine handle carriage returns in a non-standard way.

 subroutine my_filter (argptr)
 implicit none !Declare all variables.

 integer toolbx
 integer Dg_ptr, ItemHit_ptr, ev_ptr, argptr
 integer result_ptr

 integer*1 eventrecord(16)  !overlying structure
 integer*2 what  !type of event:
 integer*4 when  !time of event in 60ths sec
 integer*2 where(2)!mouse location in global
 !coordinates
 integer*2 modifiers !state of mouse button and 
 !modifier keys:
 integer*4 message !extra event information:

 equivalence (eventrecord(1),what)
 equivalence (eventrecord(3), message)
 equivalence (eventrecord(7), when)
 equivalence (eventrecord(11), where(1))
 equivalence (eventrecord(15), modifiers)

 integer aDefItem, editField
 parameter (aDefItem=Z’A8', editField=Z’A4')

 result_ptr=long(argptr+12)
 Dg_ptr=long(argptr+8)
 ev_ptr=long(argptr+4)
 ItemHit_ptr=long(argptr)

 do (i=1,16)
 eventrecord(i) = byte(ev_ptr+i-1)
 repeat

 if (what .eq. 3) then  !keydown
C  if user hits return or enter key, check the default 
C  item number.  If it is zero, then return with
C  ItemHit as the active edit text field.  If the
C   default item is nonzero, return it as the ItemHit.

 char_code=message .and. Z’000000FF’
 if (char_code .eq. 13 .or. char_code .eq. 3) then
 if (word(Dg_ptr + aDefItem) .eq. 0) then
 ItemHit=word(Dg_ptr+editField)+1
 handle_event=.false.
 else
 ItemHit=word(Dg_ptr+aDefItem)
 handle_event=.false.
 end if
 else
 handle_event=.true.
 end if
 end if
 if (handle_event) then
 word(result_ptr)=z’0'
 else
 word(result_ptr)=z’FFFF’
 word(ItemHit_ptr)=ItemHit
 end if

 return
 end

Finally, we call ModalDialog with our proc pointer:

call toolbx( MODALDIALOG, my_filter_ptr, ItemHit)

Note that if you are using this scheme to allow your program to do backround processing while you are waiting for the user to choose to do something from a modal dialog box or alert, this code should execute when a null event (what=0) is detected, and should pass the vent to ModalDialog (handle_event = .true.) if you want the text insertion point to blink. Also, if you want to handle your own application events, call GetNextEvent in the filter proc with EventMask = Z’F000' (so it doesn’t steal dialog events).

Please note that this article is not an epistle for FORTRAN as a programming language, just some help for those of us who have too much invested in FORTRAN to move to Pascal or C.

32K Limit & PMMU

Daniel Weikert

I’m now in my second year of Mac ownership and this brings about the time to decide which Mac mag’s to re-subscribe to and which to let go. MacTutor was never on the let go list, so enclosed you’ll find my renewal form and check.

I have read a lot of discussion about the “32K limit” in certain compilers lately. I have no connection with any of the compiler authors in question so I can’t say definitely why this limit was imposed, but one explanation that I haven’t seen yet is for future compatibility with systems using Motorola’s 68851 PMMU. The largest page size this chip will reserve is 32K bytes, Therefore to insure that software will run on the next generation machines which will no doubt incorporate this chip, maybe it isn’t such a bad idea to limit yourself to 32K segments.

Lazy Man’s Color Comments

Scott Boyd

Just a few comments on the article “Lazy Man’s Color” (July ’87, V3,7).

First, it appears that the author has imposed a nonexistent limitation on the size of a handle. Handles can hold as large a piece of memory as the memory manager will allocate. His statement that “the size of a MacPaint bitmap is too large to store in 1 set (32K limit)” is unwarranted. I often allocate full paint bitmaps with no adverse effects. Indeed, allocating bitmaps two and three times the size of paint document is no problem on a MacPlus.

The artificial 32K limit made the code harder to read than it needed to be.

Procedure DoSetup has the following two lines:

Title := ‘Lazy Man@s Color’;
Title[9] := CHR(39);

While that will work to create the string Lazy Man’s Color, the following statement works better:

Title := ‘Lazy Man’’s Color’;

One more thing, what’s with the alternating quotes and the hyphenated variable names in the source listings? Yuk.

PopUp Pallettes Dangers

Greg Marriott

I have recently heard from quite a few people about the unstated dangers in my pop-up article.

In my article about pop-up pattern palettes, a paragraph was inadvertently left out makes a few disclaimers about the techniques used. In the article, I outline a method which fools the Window Manager into thinking that the pop-up window was never even there, so it doesn’t generate update events. Well, the way I chose to do that is, in general, not a very nice way to treat the Window Manager. I modify the windowRecord directly, an activity severely frowned upon by the guys who make “The Rules.” The way Apple sees it, anybody using such rude coding practices deserves what they get when the system changes. They’re probably right, but it still makes me mad that I have to resort to such “anti-social” behavior to get reasonable performance.

While I’m on my soapbox, I’d like to say a few words about a problem these techniques are going to have with future Apple products. Apple is commandeering the desktop. This means every program that affects the screen outside their windows is going to run into conflicts with other programs. Take my pop-ups, for example. Since I “steal” update events and put pixels back where I got them, I allow the pop-up to cover up anything on the screen. A rather drastic change in “The Rules” means that by the time the pop-up goes away, it could be putting old pixels back where new ones should be. As a result, one of the neat features I added to OverView becomes a problem. A small shift in philosophy has to take place to accommodate new technology. Instead of preventing update events and white flashes for everybody, we must now prevent update events and white flashes only for those who don’t need them (our own windows). This can be accomplished in a few different ways; here is the way I chose to deal with the problem. Instead of emptying the pop-up window’s region (structRgn, contRgn, and visRgn), subtract the parts of your window underneath that you can get away with blasting. This can be done with successive calls to DiffRgn as follows, once for each of your windows:

DiffRgn(WindowPeek(popUp)^.contRgn.
 WindowPeek(oneOfYourWindows)^.contRgn.
 WindowPeek(popUp)^.contRgn);

Do the same for the strucRgn (I think you can ignore the visRgn), and the regions left in the pop-up window correspond exactly to the areas that don’t belong to your application. When the pop-up is hidden, update events will be generated for any windows covered by it (or at least what the Window Manager thinks is covered by it). This updated technique still modifies fields of a Window Record directly, so it still has a big red caution sign on it. The reason I won’t just use HideWindow and ValidRgn (to “un-update” our windows) is because HideWindow erases the screen before allowing me to slap the pixels back into place. This is very side-effect that prompted the article in the first place! I wouldn’t be forced to use such questionable techniques if more toolbox routines were provided for accessing low-level data structures.

MS-Basic Wish List

Michael Ching

In the April 1987 issue, we readers were asked to suggest features we would want implemented in future versions of MS-BASIC.

I imagine there would be many features people would want to be added to the language (most obviously a CASE statement for the interpreter). But in the months that I’ve been working with the MS-BASIC interpreter, my major complaints come not with the language itself, but rather with the editor.

The most annoying problem is that in order to see long lines of code, one has to horizontally scroll thereby losing the context of the other lines. It would be nice if there were an option in the editor to have the text wrap around also.

Secondly, when programming, I usually change a small section at a time and then print out that changed section to the printer. This is done by LLISTING from one label to another label. Unfortunately, this does not work with subprogram names. It would make sense if LLIST would also work with subprogram names.

Finally, the editor is just plain slow. When inserting or deleting lines in a program of non-trivial size, it takes a noticeable amount of time for the change to “ripple” through the program.

One thing that’s missing in version 3.0 is the program to cross-reference variables and labels. You can get the old program to work if you save the program to 2.00 format, but somebody out there must have already modified it to work with 3.0.

What I really would like to see is a new version which would produce a complete cross reference. As it is now, the program merely counts the number of times each label and variable is referenced. I would want a version that would tell you where each variable appeared and where each label or subprogram name was GOSUBed or CALLed from. This might prove to be an interesting programming project. (Or perhaps such a product is available?)

Likes Consulair C

Clifford Story

I got your letter in reply to my letter mentioning my preference for Consulair C over Lightspeed C. Here’s why I said that Consulair is faster:

First, I think there’s little question that Consulair compiles faster than Lightspeed, in terms of lines per second or whatever. Lightspeed gets its advantage from its integrated nature. Having compiled, it needn’t launch another application to link the result; it goes straight to link. With that speed-up, its compile-and-link time is shorter than Consulair’s and this is what people mean when they say Lightspeed is faster. I don’t deny that Lightspeed compiles and links error-free code faster than Consulair.

On the other hand, if your code contains errors, you never get to the link. Here again, Lightspeed has an apparent advantage because it has an integrated editor. Again, I don’t deny that Lightspeed compiles and returns to edit code with a single error faster than Consulair.

My code is rarely so clean, particularly when I am writing in C. With, say, five errors in the code, Lightspeed finds the first one-- and dies. You have to repeat the cycle five times to get all the errors. With Consulair, once is usually sufficient-- it will find errors, record them, and keep on going. Lightspeed forces you to remain at the desk during a compile and hold its hand. Consulair lets you play with the cat.

Well, I wrote a 68000 disassembler in C, for the experience, and now I’m back to TML Pascal and MDS. That’s what I really like.

MPW Pascal Integer Divide Bug

Scott Taggart

MPW has a bug concerning integer divides of SIGNED integers. When a signed integer (I think both 16 and 32 bit integers have the same problem) is divided by a CONSTANT that is a power of 2, the compiler optimizes this into this into a right shift. Unfortunately, the right shifting of a number to simulate a divide produces correct results ONLY if the number being divided was a POSITIVE number. If, however, the number being shifted is negative, the results MAY be incorrect. The result are sometimes correct depending on the value of the dividend. For example, the result of -10 div 4 when shifted yields -3, while -8 div 4 yields the correct result of -2.

Note that this problem only occurs when the dividend is negative and the divisor is a constant and a power of 2. If the divisor is a variable, and that variable happens to contain a power of 2, the compiler must generate a call to do a ‘real’ divide because it does not know the value of the variable at run time.

This problem did not exist with the Lisa Pascal compiler, as it ALWAYS called a library routine to perform a ‘real’ divide when the dividend was signed.

A short term ‘fix’ to the problem is to place power of 2 divisors into a variable. For example:

var x : integer;

x := -10;
x := x div 4{ yields bad value of -3 }

While:
var x, v4 : integer;

x := -10;
v4 := 4;
x := x div v4; { yields correct result of -2 }

This bug was reported to Apple on 7/6/87.