Sannyasin Brahmanathaswami wrote:

> Yes, I did try. and certainly any manual resizing fires the resize
> msgs as expect.

Excellent. You now have one trigger point for the sequence of resizing actions when a stack is opened or the orientation is changed.

If you have multiple cards and you need to trigger that on each, you can do so from one handler in the stack:

   on preOpenCard
      resizeStack the width of this card, the height of this card
   end preOpenCard

Each card is responsible for the layout of its groups in its resizeStack handler, each group is responsible for itself in their respective resizeControl handlers.

There are many ways to handle resizing, but for me this works well, allowing me to keep the internals of a group handled by that group itself.

> But the interest was, initially, to get the resizeControl to fire from
> script. As resizeable it off of all stacks -- deliberately so team
> does not inadvertently break their rect with the slip of a drag/save.
> I was "pedal to the metal" on reading the dictionary.  but later found
> ----------
> The resizeControl message is 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).
> The resizeControl message is sent after the resizing is finished.
> This means that you cannot prevent a control's size from being changed
> by trapping this message.
> ------
> Hence the need for  custom handler to do the work as these commands
> appear to be dedicated to an actual "physical" user interaction,

Or so it might seem, had you and I not already spent considerable time in private email on this, where a few days ago I wrote:

     The messages added in the v4/5 series are especially useful -
     that's when behaviors started being taken seriously, and there
     was much interest in custom controls. We got things like "before *"
     and "after *" message options for behaviors, and "preOpenControl"
     and the less-commonly-needed "openControl".

     Another key change is when "resizeControl" is sent: historically
     that was only sent to controls when resized with the pointer tool,
     but in recent versions that message is sent to groups whenever
     anything changes their rect, even other scripts.

Those changes occurred before the standard practice the team uses today, in which language element changes are now not considered complete until the Dictionary has also been updated to reflect them. Back then they were on a separate track, and a few additions fell through the cracks.

I caught this one a couple years ago, and filed a bug report for it:

See also this request by Mark Waddingham, which will simplify the subset of cases involving disabled groups (would love to see this in v9):

> set the rect of group "responsiveAboutBox"  to 50,50,400,760
> also constitutes a "resize" event, so it would be "cool" if the
> resizecontrol msg were also handled.

For group controls you will find that it is. Try it.  It's quite handy.

> But custom responsive handlers also work. The method I worked out:
> using a single object's (member of the group) rect as the base
> coordinate system for all siblings in the group, seems pretty straight
> forward. The idea being not just to have the control change on stack
> orientation shift or different device screen, but to change to a
> custom rect on demand…

Yep, lots of ways to handle dynamic layouts. Glad you found one that works well for you.

 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to