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

[Wilhelm Sanke]

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.


Until these bug will have been fixed, this leaves us with three options 
for workarounds for the time being:

1. Use the "magic button"

This seems to be indeed the simplest solution as it works under all 
conditions and also with and without scrollbars - and you set the 
necessary properties only once.

As you know from my report (the first post of this thread) the button 
has to be visible in the sense that the vis of the button must be true. 
If you really "hide" it - with hide or set the vis to false - the effect 
is lost. Another prerequisite is that the button is placed at the 
topleft corner of the group.
But you can make the button invisible to the eye of the user by setting

- the showname, showborder, show hilite etc. to false
- the ink of its color to noop
- the layer of the button in the group to the lowest.

Additionally you could comment out the script of the button or put empty 
into it to prevent the button being accidentally dragged somewhere 
because of the "grab me" script in my sample stack.

You could also make the button very small; size does not matter to 
achieve the effect.

Why the magic button works at all is still a mystery to me.

2. Toggle the hscrollbar and the vscrollbar on and off

In my configuration of the image-processing stack I needed the 
scrollbars for images that are larger than the group. In this case of a 
larger image "set the loc of image x" works fine with visible scrollbars.

You would have to check - when importing an image or retrieving an image 
stored inside the stack - what the size of the image is , and set the 
scrollbars accordingly. That would mean to add appropriate script lines 
to each handler in the stack that imports images or sets images from 
inside the stack.

There is one difficulty here as the size of the image has to be larger 
in both dimensions - horizontally and vertically - for the "set" command 
to work properly with scrollbars turned on, .e.g. meaning that if the 
image is higher than the group and the scrollbars are on you cannot set 
the loc accurately: the y-part of the loc will be set accurately, but 
the image will snap to the left side of the group -

Of course - as a different configuration of an image-processing stack - 
one could dispense with scrollbars altogether, and let the user drag the 
image around with a "grab me" script.

3. Use "move to" instead of "set the loc"

This workaround is the least comfortable. Although "move image x to x,y" 
or "to the loc of group y" ( if you add "in 1 millisecond") it will set 
the image at once and reliably to the intended place, you have then to 
cope with the problem of "keeping" the image at its loc - see the 
conditions listed above.

You would need to add the scriptline "move to..." in quite a number of 
handlers, in the preopenstack handler of the card, in each filter script 
that adresses imagedata - there may be hundreds of such filters in an 
image-processing stack -, in the "import image" handler and elsewhere.

By the way, the effect involving imagedata is not because imagedata are 
changed in any way, but because they are "set". "Set the imagedata of 
img x to the imagedata of img x" will also cause to place the image in 
the topleft corner of the group.--

Some deliberations for the Revolution engineers that will try to fix 
these bugs:

The first places to look for would probably be the codes in the engine 
for the "set loc" and "move to" commands. There must be a distinctive 
difference in the "move to" code that overrules the effects caused by a 
"smaller image in a group" and the influence of turned on "group scrollbars"

Another approach.might be to analyse the internal differences between 
the variants of the "two-step" effects triggered when you "set the loc" 
or "set the imagedata".

With "set the loc" after the first step - using the command once - only 
that portion of the image will be displayed that is identical to the 
overlapping parts of the image set to the topleft corner of the group 
and the area the image would have occupied when it would have been 
really centered. Only after applying "set the loc" another time the 
image will be fully displayed in the topleft corner.
This effect is independent of the place where you might have dragged the 
image to before you used "set the loc".

This special overlapping effect with the "set" command points to fact 
that somehow the area - which would have been occupied by a centered 
image - is treated differently and that "set the loc of img x to the loc 
of img y" apperently produced some kind of result for this area, 
although not the intended one.

With "set the imagedata" the portion of the image being displayed after 
the first step is defined by the overlapping parts of the image at a 
topleft position and the current position of the image before the first 
"set the imagedata" command was applied. This also means that after the 
first step the image might be totally invisible if you had dragged the 
image to a position where no overlapping occurs.

If you click in the area of the image at its topleft position after the 
first step you can revive the missing parts of the image. When you add 
"lock screen" before the "set loc" or "set imagedata" line the image 
will at once be displayed in the topleft corner - without a second step.--

It might be worth exploring whether these image-related peculiarities 
are somehow and distantly connected to other Revolution-specific image 
properties as, for example,  what I have called "pre-PNGs" in my stack 
"More about Masks" and in several posts to this list. An image in a 
stack created by a snapshot (and remaining in the stack or copied and 
pasted into another stack) behaves differently in some aspects from an 
image already saved externally or imported into the stack.-

During the last two years much of my time devoted to programming with 
Revolution was spent in the field of image processing of various kinds. 
I suppose - with a rough estimate - that I spent 20 to 30 percent of 
this time to detect the causes of crashes and to find workarounds for 
less fatal bugs, time I could have really used more creatively - 
although of course bug-hunting in itself can be challenging and interesting.

If you consider this lost time and add the fact that bug reports could 
remain with absolutely no feedback for almost a year, then you might 
understand that anger and frustration can come up. Hopefully, according 
to the new policy announced by Kevin, this will now change.

Regards,

Wilhelm Sanke
<http://www.sanke.org/MetaMedia>