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

[Wilhelm Sanke]

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 
like this:

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 
peculiarities.
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 --


Best  regards,

Wilhelm Sanke