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. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode