Harry Potter's magic button - a solution to another tricky group bug
sanke at hrz.uni-kassel.de
Wed Aug 4 06:20:20 EDT 2010
On Tue Aug 3, 2010, J. Landman Gay jacque at hyperactivesw.com wrote:
> I downloaded your stack and took a look. The problem isn't an unlocked
> group (your group was locked.)
Jacqueline, really thanks for taking a look. Thanks to the others who
gave feedback, too, but I think by responding to Jacqueline's questions
I can cover most of the issues.
I did *not* say that the problem is connected to an unlocked group. In
fact, I stated somewhere in the report, that both the
image-to-be-centered and the group have their lockloc set to true. I
should have mentioned this at the beginning.
The scenario I came across this bug - or rather a whole can of bugs - is
In an image-processing stack I put the image to be processed inside a
group. The idea is to be able to display images of any size, images that
are larger than the fixed rect (800x600) of the group can be scrolled by
the horizontal and vertical scrollbars or inspected with "mousedown and
dragging the image" directly. Besides that there is an option to display
the image as a whole adjusted to a separate window covering the full screen.
So in this scenario the scrollbars are necessary.
Of course there are other possibilities for an image-processing stack to
display the processed image without using a group, as we have done in
another joint project, where a "copy" of the image is shown in a display
image of fixed size: The "real" image is hidden, but at the same time
transferred to the display image. When the hidden image is changed
through filters or otherwise this change will then immediately be
reflected via the text-of-image property in the visible image.
> It seems to be the scrollbars around the
> group. If I turn them off, it all works as expected.
Unfortunately not quite!
> The work-around would be to turn off scollbars, set the loc of the
> image, and then turn them on again. It should happen pretty fast, but
> you could lock the screen in case.
When you turn the scrollbars on again, the image will immediately snap
to a topleft position again - like it does in some other cases I
mentioned (going to another card and back, changing the imagedata etc.)
> So something about a group with scrollbars is causing the problem but I
> can't tell what.
Neither can I, but I think there is more involved than just the scrollbars.-
Another test I just did: When you turn the scrollbars off and use one of
the three scripts of the "automated demonstrations" the stack at once
crashes/freezes after having set the image to the center.
> By the way, the image doesn't always pop to the top
> left of the group. If you drag it past the bottom right corner, for
> example, it will go almost to the center (but not quite.)
That is not correct. As it were, you are the victim of an optical
delusion here, you see only a part of the image! I had described that in
my report as the "two-steps" effect:
The full image will be visible at the topleft position, if you "set the
loc of img x to the loc of group y" a second time or click at the area
of the image.
Moreover, like with test button "duplicate colors - lock screen", the
image full image will be displayed at once at the topleft position when
you add the line
"lock screen" before line
"set the loc of image "x" to the loc of group "y"".
> I'm not sure why the extra button makes a difference, unless it simply
> jolts the engine into realizing where the topleft corner of the group is.
That seems to be indeed part of the magic of Harry Potter's button, like
also the interesting split-button effects.
It will be the task and the pleasure of the Revolution engineers to find
out what is going on. And they should also contemplate, why the
alternate possibility to center the image using "move to the loc of
group x" works in all cases (with or without scrollbars), but not "set
the loc to the loc of group x"
> It would be good to update the bug report so the team knows what exactly
> to look at.
If I knew myself what is going on behind the scenes, I could of course
have told them, but I don't.
As the report was already rather long, I have left out some other
For instance, setting the loc of the image *not* to the loc of the
group, but to other x,y coordinates will also produce unexpected results
especially if x,y are near or beyond the borders of the group.
Also, when saving the stack, it can happen that the part of the image
which was under the window of the save dialog will be moved horizontally
for a number of pixels. I have not yet found out the exact conditions,
so I cannot reliably replicate this, but it happens from time to time --
More information about the Use-livecode