quirk in group resize behavior

[Monte Goulding]

Hi Folks

One of the recent issues in the IDE caused us to discover/rediscover a quirk in group resize behavior that I think would be worthwhile getting feedback on from the community. I’m personally struggling to come up with a use case for it although there very likely is/was one. Perhaps one of the newer group properties resolved the use case in a better way.

When you resize a group using the selection handles the controls inside stay where they are. This is quite helpful. The code that does that also has an extra condition which means the controls inside the group will also stay where they are if resizing an unselected group via code but not changing the bottomRight of the rect. This essentially makes the group appear scrolled even though the scroll property is unchanged. At the very least this behavior needs to be documented, however, I can’t help feeling that it is unexpected behavior and a reliable rule of changing the topLeft of a group shifting its controls that amount would be more helpful.

An example of this issue can be seen in the script editor in the IDE where when you use the resizer to alter the width of the handler list the interactive find is not moving correctly. This is because the amount being added/subtracted to the topLeft of the group is the exact same amount being subtracted/added to the bottomRight.

The code making it do this is unchanged since LiveCode went open source. I expect it has been this way for a very long time and I have a feeling that I know why at one point… If it is something that people depend on than it may be we can only document as an anomaly or would need to add an extra group property to override it.

Any thoughts from the community would be appreciated.

Cheers

Monte