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 
             show me
end setMyVisState pBool

Sure, OK, no problem that works… 

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

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
   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" 
   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


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.

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

Reply via email to