Harry Potter's magic button - a solution to another tricky group bug
sanke at hrz.uni-kassel.de
Fri Aug 6 13:01:27 EDT 2010
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
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
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
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.
More information about the Use-livecode