href=http://www.son.washington.edu/Toolbook/brianp.html>brianp@u.washington.edu ALAN ROGERS writes:

 
>>Recently I discovered a BUG in tb3.0a which causes icons on buttons to
>>appear larger and distorted on some systems running at 800 x 600, set
>>to large fonts. (Chunky looking)
 
>>A bug is a bug, right?
 
Well Alan, as always a bug is in the eyes of the beholder, one man's bug is another man's feature.

ToolBook works in a device independent coordinate system where units are measured is pageUnits (twips). There are 1440 pageUnits in a logical inch on every device. Most display drivers that offer a large fonts mode change the number of logical pixels per inch to keep the aspect ratio of the fonts appealing. This has the effect of changing the number of pixels per page unit. That means that since ToolBook object's bounds are specified in pageUnits a ToolBook object's bounds will be a different number of pixels depending on the display driver. ToolBook has done this since version 1.0 and it means that if a book is run on a device with a different number of page units per pixel the width and height of the object will be a different number of pixels. Time for an example:

On standard VGA there are 96 pixels to the logical inch. That means that a line that is 1440 page units long will be 96 pixels long on standard VGA. If that line happens to be part of a nifty raised or inset frame for a 96 pixel wide bitmap everything is OK. If that page is displayed on a large fonts driver there are 120 pixels per logical inch ToolBook will draw the line 1440 page units long (as you would expect) but the line will now be 120 pixels long instead of 96 pixels long. Since the line is a border for your bitmap it is really nice that ToolBook stretches the bitmap so that it is now 120 pixels wide so that it still lines up with your other ToolBook objects.

Follow that?

When graphics were added to ToolBook buttons it made since to the developers that they would work the same way all other ToolBook objects work and the graphic would be stretched or shrunk by the same amount as the button displaying it. Seems to make since unless you are doing a tool bar or tool palette with small graphics and notice that they really look like crap if they are stretched. Since it is possible to align ToolBook objects with graphics on buttons the behavior stood and no *special* rights for button graphics.

When I did the dialog editor I wrote scripts to reset the graphics on enterApplication (I believe) so that they would not be stretched. On a large fonts driver this means that the graphics are a little smaller in the middle of bigger buttons but the still graphics look great. In other applications I have written scripts to re-size the button to the size of the bitmap resource as well as reset the graphic so it isn't stretched, works great. Here is an example:

notifyBefore enterPage
	ls = lockScreen of this window
       	set lockScreen of this window to TRUE
       	get resourceInfo of bitmap "backdrop"
        -- calculate the size of the bitmap in pageUnits
        get item 2 of it * item 1 of sysPageUnitsPerPixel,item 3 of it * item 2 of sysPageUnitsPerPixel
        set my size to it
        -- reset the normalGraphic so it set to the current logical pixels per inch
        set my normalGraphic to null
        set my normalGraphic to bitmap "backdrop"
        set lockScreen of this window to ls
end
For MTB30a after some last minute lobbying it was decided that stretching of button graphics, since button graphics are used for tool bars and tool palettes, was not desired and the behavior of button graphics is given special treatment and they are not stretched.

It is a very important step in producing your application to run it under different resolutions, large fonts/small fonts, (if you are allowing it to be run under different resolutions) and observe how it looks. Any time the logical pixels per inch are different from your development machine (where you imported the bitmap or picture) things will be stretched and you might decide you need to do something about it.

Maybe the largest set of users want the new behavior, but I guarantee there is someone who designed their application believing they could rely on the alignment of their button graphics. If you have ToolBook draw objects aligned to graphics on buttons you will have to re-align them from script your self if you use MTB30a.

Jeffrey Ayars
Asymetrix Corporation

Revised 5/5/95
brianp@u.washington.edu (Brian Parkhurst)
University of Washington
Box 357260
Seattle, WA 98195-7260
206/543-9175