Interface question

[J. Landman Gay]

In case anyone is interested, I thought I'd let people know how we 
decided to resolve the interface issue I was having with a client's 
stack. This was the problem:

> Because the prefs stack is much smaller than the print template stacks,
> the text entry fields are also not as wide. To give the user a way to
> visualize how their tabstops will look, the textsize in the entry fields
> is very small. This gives the right ratio between field width and text
> size, so that they get a fairly accurate idea of the text placement in
> the header or footer as they slide the tabstops around.
> 
> So now the client says the text is too small to read easily (which is
> true) and he'd like it legible. Problem is, if I increase the text size,
> the relative ratio of the tabstops will not be accurate and the fields
> will not display the relative text placement correctly.

I got lots of good answers here but they all involved some kind of 
second field, which I wasn't keen on. Someone had suggested a magnifying 
glass effect, but that doesn't allow easy editing. It did give me an 
idea though. The upshoot is that we decided to implement a dynamically 
resizing field, which for our situation works pretty well.

When the insertion point is placed in one of the two relevant prefs 
fields, it grows horizontally and a little bit vertically. The font size 
and textheight are changed proportionately, which makes it readable. A 
colored border is added to show that the field is in a special state. On 
exitField and closeField, the field size and font properties are reduced 
back to normal and the border removed.

It works pretty well, seems intuitive, avoids an extra editing field, 
and has a semi-animated effect. (I'm considering adding a visual effect 
to amplify that.)

--In each prefs field:

on openField
   zoomFld "large"
end openField

on closeField
   zoomFld "small"
end closeField

on exitField
   zoomFld "small"
end exitField

--In the card script:

on zoomFld pSize
   put the short name of the target into tFldName
   put the uRect of fld tFldName into tNativeRect -- custom prop stores 
native size
   lock screen
   switch pSize
   case "large"
     put the loc of fld tFldName into tLoc
     set the threeD of fld tFldName to false
     subtract 10 from item 1 of tNativeRect
     add 10 to item 3 of tNativeRect
     add 5 to item 4 of tNativeRect
     set the rect of fld tFldName to tNativeRect -- now adjusted
     set the loc of fld tFldName to tLoc
     set the textsize of fld tFldName to 13
     set the textheight of fld tFldName to 18
     break
   case "small"
     set the threeD of fld tFldName to true
     set the rect of fld tFldName to tNativeRect
     set the textsize of fld tFldName to 9
     set the textheight of fld tFldName to 16
     break
   default
   end switch
   unlock screen
end zoomFld

I didn't need a direct command to set the border, because toggling the 
threeD property toggles border visibility. So all I had to do was 
manually set up the border width and color, and then just turn threeD on 
and off.

Maybe someone can use this. It's a simple solution that I just didn't 
think of until you guys jogged my brain. Thanks.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com