Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin]

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:
http://quality.livecode.com/show_bug.cgi?id=17118

See also this request by Mark Waddingham, which will simplify the subset 
of cases involving disabled groups (would love to see this in v9):
http://quality.livecode.com/show_bug.cgi?id=17123


 > OTOH
 >
 > 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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com