I have been thinking about it, and if you accept that when you set a behavior it's like inserting the script of the behavior object in front of the target (or by your diagram on TOP of the target). So syntactically, it's the complete opposite of what *actually* happens, but in terms of the message path, it's correct.
When I attempted to do this the way I suggested, the datagrid "broke" that is nothing about the datagrid functioned as such. Clicking a row did not halite the row. SelectionChanged was never sent when clicking any populated row. By doing it the way Bernd suggested, it worked as expected. I think there was some discussion about this when nested behaviors first came out. Bob S > On Jul 19, 2018, at 15:44 , Richard Gaskin via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Bob Sneidar wrote: > > What I did (which actually makes a LOT more sense) is I set the > > behavior of the button to the behavior of the datagrid, then I set the > > behavior of the datagrid to the long id of the button. That broke it. > > Your way sounds better to me. > > If I understand correctly, what you're doing is: > > [ DataGrid ] > | > V > [ Custom Behavior ] > | > V > [ Standard DB Behavior ] > > That seems best, because it allows you control over the scope of your custom > behavior. > > If the last two were swapped then all DGs would inherit whatever's in your > custom script. > > Why didn't that work? Did you pass all relevant messages? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web _______________________________________________ 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
