quirk in group resize behavior

[Terry Judd]

Yeah, I often get caught out resizing groups and finding that I¹m adding
unnecessary/unexpected space or cutting off controls when really what I
want to do is anchor the child controls on one or two axes when I grow or
shrink the group. Being able to set a reference edge or corner (L, T, R,
B, TL, TR, BL, BR) and hold that stable when you resized the group would
be cool with the default behaviour being as it is already (resizing around
the current loc?).

Terry...

On 21/06/2016 9:17 am, "use-livecode on behalf of Monte Goulding"
<use-livecode-bounces at lists.runrev.com on behalf of monte at appisle.net>
wrote:

>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
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode