resizeControl wishes...

[ambassador at fourthworld.com]

Craig Newman wrote:
> “reSizeControl” is a message. What I mean by that is if you are already
> running under script control, why do you need to send such a message at
> all? Can’t your handler do whatever you needed to if the user did the
> actual resize action?

He's asking about resizing that takes place outside of direct user interaction with the pointer tool, such as during a resizeStack event.


Paul Dupuis wrote:
> resizeControl is sent "only sent when the user resizes a control by
> dragging its handles. It is not sent if a handler changes the size
> of a control by changing its properties (width, height, and so on)."

That appears to be a documentation bug. IIRC the change you're looking for was introduced way back when the DataGrid premiered. Without it the DG wouldn't be able to cleanly update its internal groups.

Here's a simple test stack confirming the change:
https://fourthworld.net/lc/Resize%20Confirmation.livecode

-- Card script:
on resizeStack
   set the rect of grp 1 to the rect of this cd
end resizeStack


-- Group script:
on resizeControl
   put item 2 of the loc of this card into tMid
   set the rect of fld 1 to the left of me,the top of me,the right of me,tMid
   set the rect of fld 2 to the left of me, tMid, the right of me, the bottom of me
end resizeControl

Tip: Set the lockLoc of such groups to true, to override the engine's default behavior of adjusting group size to fit contents.


Now that the engine sends resizeControl to groups under both user interaction and script directive, handling the resizeStack message is MUCH easier than before.

Among other things, it lets you encapsulate code within groups for reuse.

But even if your groups are one-offs not needed elsewhere, the benefits of encapsulating the LOGIC of putting things where you want them is immense.  It's so much easier to express the placement of objects within a group than relative to the group within a card.

I'd guess that not having this sooner, and not documenting it after delivery, may contribute to the cottage industry of clck-click-click-click-click-click-click-click-click-click options for handling resizing with things like the Geometry Manager and various other tools and options.  All of them are utimately responding to the resizeStack message, but in a generalized way that adds a large layer of complexity, and sometimes uncertainty.  Handling resizeStack directly is with-the-grain; it uses the power of the engine to its most efficient, preditable, and robust advangage to put things exactly where you want them.

--
Richard Gaskin
FourthWorld.com