Precicely why I wanted to nest datagrid behaviors. This is working really well for me by the way. I have about 8 datagrids on what I call the Main Form, all running the same nested behavior inserted before the default datagrid behavior. If I need grid-specific code called from the behaviors I simply put that code in the datagrid script itself, then use dispatch, as it will not fail if it cannot find the handler (brilliant idea that).
My other "form" stacks all have another nested behavior. Bob S > On Dec 26, 2018, at 21:20 , Trevor DeVore via use-livecode > <use-livecode@lists.runrev.com> wrote: > >> 3) What do you think of nested behaviors, where the "uber parent" is a >> model and the child behavior is a view/UI behavior, controller VS just >> keeping that model in libraries that remain open all the time? Goes to #2 >> above. >> > > While I've never done it that way (I have defined my model interfaces in > library stacks out of habits established prior to behaviors) there could be > value in that approach. Take a model interface that can have multiple > instances of the model. If you use a library script you have to pass a > model instance identifier to every handler in the library. Using a behavior > script attached to a card could remove that need as each behavior has it's > own instance of the script local variables used in the model behavior > script. The approach could also simplify callbacks because the target would > always be the object the model behavior is attached to. _______________________________________________ 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
