Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami]

Oh boy, this custom control thing is awesome + external behaviors as text only scripts… What a break through! At 60+ should not get too excited about anything, but this has my brain on fire.  I even took all the code out of the control, moved it to a behavior… and then, even for buttons the *only* logic needed in the control is the name.. remove or pass the mouseup then trap in the behavior with "target" and now we have a true "zero code" binary "view" object 

Wow! too much fun.

OK.. I decided for instantiation for now just to adopt Terry's option:

"I usually include it as a shared group and place it on any card that might require it and show/hide, populate and layer it dynamically as required."

this saves the dev time needed to do a complete "create from outerspace" script for now.  Until a use case for creating on the fly comes up, I'll just copy this group "around" as needed.

But there is a caveat here: once the card is open, the preOpenControl and openControl no longer fire. Of course, that would be expected behavior.

Given that many of us do GUI on a single card composed of multiple objects/groups that are simply hidden or shown on demand.  I thought, why not request an enhancement "on preShowControl"  or "on showControl" and "on hideControl" could be very useful.

of course you can roll your own, but the you have to things like

dispatch "setMyVisState" to group "info-diplay" with "true"

then your behavior has  to do stuff like:

on setMyVisState pBool
  switch pBool
	 case "true"
      		# set up some controls for internal animation in the group control
             show me
             break
end setMyVisState pBool

Sure, OK, no problem that works… 

But thought, hmm maybe the language has something mysteriously hidden like clipsToRect.

So I looked up "before" into the dictionary, thought.. Ha! there it is: this is a "no brainer"
just make a behavior for the group and add this to the behavior

before show  
     #  Oops fails to compile
     # "button "info-display-behavior": compilation error at line 1 (
     #  Handler: bad handler name (may be reserved word)) near "show", char 1
     
   answer "hello" with "OK"

end show

on mouseUp
   put the short name of the target into tMouseEvent
   switch tMouseEvent
      case "close-info"
         hide me
         break
   end switch
end mouseUp

on resizeControl
   lock screen
   set the clipstoRect of me to true
   set the width of grc "info-field-bkgnd" to the width of me * .95
   set the height of grc "info-field-bkgnd" to the height of me * .95
   set the width of fld "info-text" to the width of me * .85
   set the height of fld "info-text" to the height of me * .85
   set the loc of  img "info-bkgnd-img" to the loc of me
   set the loc of grc "info-field-bkgnd" to the loc of me
   set the loc of  fld "info-text"  to the loc of me
   set the right of widget "close-info" to the right of grc "info-field-bkgnd" -8
   set the top  of widget "close-info" to the top of grc "info-field-bkgnd" +10
   set the loc of me to the loc of this card  
       unlock screen  

# but the default state is vis false so:

   show me with visual effect dissolve very fastend resizeControl

OK so *why* is 

before mouseup  # valid syntax

But

before show # invalid

??





   




> Maybe a better message to trap in this case would be preOpenControl or
    > openControl, which is sent to a group the first time it is accessed or
    > when the card opens, depending on whether it's a background or card
    > group.
    
    Yep, those are good triggers too, still allowing the group to manage its 
    own contents.