Harry Potter's magic button - a solution to another tricky group bug

[J. Landman Gay]

On 8/6/10 12:01 PM, Wilhelm Sanke wrote:
> I need to rephrase the bug definition after Jacqueline has found out
> about the effect of the group scrollbars:
>
> "If an image is smaller than the dimensions of a group and the
> vscrollbar and the hscrollbar are set to true, then you cannot set the
> loc of the image to the loc of the group or reliably to any other x,y
> coordinates."
>
> Actually, there are at least two bugs: The problem of "setting" the loc
> and that of "keeping" the loc - although the lockloc of the image is set
> to true. "Lockloc" in the context of the definition above is also broken.
> After having succesfully centered the image, it will - as reported -
> revert to a topleft position in the group
>
> - when you go to another card and then navigate back
> - when you set the imagedata
> - when you import a new image
> - when you toggle the scrollbars back to true
> - when you close the stack (even after having saved it again) and then
> reopen it.

(snipping rest)

All these, plus other issues you describe in the rest of the message, 
boil down to the same thing: the loc of the image isn't applied 
correctly whenever the group (or card, perhaps) is redrawn. Everything 
in the above list redraws at least part of the card. Even just moving 
the image causes a redraw.

When I did my brief tests it looked like the "set" command ignored the 
requested location, even if I stored it in a variable first:

   get the loc of grp "imagegroup" -- this was identified correctly
   set the loc of img "eins" to it -- didn't work

This only failed when the group had scrollbars. So I think setting and 
keeping the requested location are really the same problem, and fixing 
one will likely fix the other.

I think you can probably revise the bug report with that info and it 
will be enough for the team to identify the issue, especially if you 
upload your example stack which makes the problem quite clear.

To work around it, I altered your button script to open images this way:

on mouseUp
   answer file "Choose image" -- with filter "*.jpg;*.png"
   if it is empty then
     exit to top
   else
     put it into tfile
     put "binfile:" before tfile
     set the lockloc of img "eins" to false
     lock screen
     put URL tfile into img "eins"
     set the lockloc of img "eins" to true
-- changes start here:
     put (the width of img "eins" > the width of group "imagegroup" \
            or the height of img "eins" > the height of \
            group "imagegroup") into tIsLarge
     set the hscrollbar of group "imagegroup" to tIsLarge
     set the vscrollbar of group "imagegroup" to tIsLarge
     unlock screen
   end if
end mouseUp

BTW, I had to comment out the "with filter" which doesn't apply on Macs. 
If you will be distributing this cross platform, use "with type" instead.

Since you only have to work around the problem when the image is opened 
or reset, you shouldn't need to add anything else to other handlers. 
Leave the scrollbars alone except when changing or importing an image.

This worked in your sample stack.

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