Datagrids and Nested Behaviors

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Hi all.

I'm finally taking the plunge with nested behaviors with datagrids. Essentially, I have a button named "modulegrids" whose behavior is set to stack "RevDataGridLibraryBehaviorsDataGridButtonBehavior" (the new default behavior of a datagrid). I then set the behavior of a datagrid to the long id of that button. The behaviors are triggering alright, but selectionChanged is not *actually" changing the selection, and calls to the library such as the dgHiliedIndex of the datagrid return empty.

So my question is, can behaviors be nested for datagrids?

Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Hi Bob, If you really wanna make things interesting ..... try putting a
grid inside a grid..... lol..... it almost works.  Which means to me that
"self referencing" is imperfect in the grid library.  that might pertain to
the problems you experience ....and without the ability to debug the grid
library...its tough going.  But i think I have learned that sometimes when
i find i can't just get something right....i end up finding a way easier
way later..hope thats the case for you,

On Mon, Jul 9, 2018 at 2:11 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Hi all.
>
> I'm finally taking the plunge with nested behaviors with datagrids.
> Essentially, I have a button named "modulegrids" whose behavior is set to
> stack "RevDataGridLibraryBehaviorsDataGridButtonBehavior" (the new
> default behavior of a datagrid). I then set the behavior of a datagrid to
> the long id of that button. The behaviors are triggering alright, but
> selectionChanged is not *actually" changing the selection, and calls to the
> library such as the dgHiliedIndex of the datagrid return empty.
>
> So my question is, can behaviors be nested for datagrids?
>
> Bob S
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Hi Tom.

I usually find a way around things myself, but in this case, not. I have a main form, where all the datagrids behave the same way on doubleMouseUp, selectionChanged etc. I then have what I call subForms (substacks that detail a given table and it's dependent tables like devices and accessories for example) that behave in a different way, but all subForm datagrids have the same behavior, different from the main form.

I was hoping to be able to insert a special behavior between the datagrids and the default behaviors. I also tried what apparently used to work, copying the datagrid behavior to a button then setting the datagrid behavior to the new button. That also does not work.

Bob S


> On Jul 18, 2018, at 17:10 , Tom Glod via use-livecode <[hidden email]> wrote:
>
> Hi Bob, If you really wanna make things interesting ..... try putting a
> grid inside a grid..... lol..... it almost works.  Which means to me that
> "self referencing" is imperfect in the grid library.  that might pertain to
> the problems you experience ....and without the ability to debug the grid
> library...its tough going.  But i think I have learned that sometimes when
> i find i can't just get something right....i end up finding a way easier
> way later..hope thats the case for you,


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Actually Tom, I think I figured out a way around this. I've already put my stack scripts for the subModules into behaviors. By adding a selectionChanged handler in that behavior and checking to see if the dgControl of the target is empty, I can pass selectionChanged for fields and handle it for datagrids. Word 5 to -1 of the dgControl is the long id of the datagrid.

The only bugaboo will be when I send selectionChanged. The target will not be a control of the datagrid, but I can work that out easily enough.

Thanks for kicking my mind in the butt.

Bob S


> On Jul 19, 2018, at 07:38 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Hi Tom.
>
> I usually find a way around things myself, but in this case, not. I have a main form, where all the datagrids behave the same way on doubleMouseUp, selectionChanged etc. I then have what I call subForms (substacks that detail a given table and it's dependent tables like devices and accessories for example) that behave in a different way, but all subForm datagrids have the same behavior, different from the main form.
>
> I was hoping to be able to insert a special behavior between the datagrids and the default behaviors. I also tried what apparently used to work, copying the datagrid behavior to a button then setting the datagrid behavior to the new button. That also does not work.
>
> Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Correction the target is still the datagrid. I thought for some reason the target would be the sender.

Bob S


> On Jul 19, 2018, at 08:00 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> The only bugaboo will be when I send selectionChanged. The target will not be a control of the datagrid, but I can work that out easily enough.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
One of the many reasons I love livecode...control references and message
path work so well together ... giving us endless variety of approaches to
any task.  nice job. see ya bob

On Thu, Jul 19, 2018 at 11:09 AM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

> Correction the target is still the datagrid. I thought for some reason the
> target would be the sender.
>
> Bob S
>
>
> > On Jul 19, 2018, at 08:00 , Bob Sneidar via use-livecode <
> [hidden email]> wrote:
> >
> > The only bugaboo will be when I send selectionChanged. The target will
> not be a control of the datagrid, but I can work that out easily enough.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
Bob,

if you want to use a a behavior for the datagrids make a button with

on mouseDoubleUp
   put the long name of the target
end mouseDoubleUp

and then set the behavior of your datagrids like this

set the behavior of the behavior of the behavior of group "datagrid 1" to the long id of button "myButtonName"


this will put the "new" behavior at the top of the two behaviors of the datagrid group. Obviously that will not work with editable fields.

Kind regards
Bernd
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Bernd, you are a genius. I apparently have the heirarchy of behaviors backwards. I would have thought that this would set the behavior of ALL datagrids to include the button script. That of course would be disasterous.

Bob S


> On Jul 19, 2018, at 10:35 , Niggemann, Bernd via use-livecode <[hidden email]> wrote:
>
> Bob,
>
> if you want to use a a behavior for the datagrids make a button with
>
> on mouseDoubleUp
>   put the long name of the target
> end mouseDoubleUp
>
> and then set the behavior of your datagrids like this
>
> set the behavior of the behavior of the behavior of group "datagrid 1" to the long id of button "myButtonName"
>
>
> this will put the "new" behavior at the top of the two behaviors of the datagrid group. Obviously that will not work with editable fields.
>
> Kind regards
> Bernd


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Come to think of it, this IS backwards, but it works.

The behavior of group datagrid 1 is by default button id 1005 of stack "revDataGridLibrary"
the behavior of button id 1005 of stack "revDataGridLibrary" is stack "RevDataGridLibraryBehaviorsDataGridButtonBehavior"

so what your statement *should* be doing is setting the behavior of stack "RevDataGridLibraryBehaviorsDataGridButtonBehavior" to a button in another stack! That is WAAAY convoluted, that it actually inserts the behavior at the TOP of the message path.

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.

Bob S


> On Jul 19, 2018, at 13:44 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> Bernd, you are a genius. I apparently have the heirarchy of behaviors backwards. I would have thought that this would set the behavior of ALL datagrids to include the button script. That of course would be disasterous.
>
> Bob S
>
>
>> set the behavior of the behavior of the behavior of group "datagrid 1" to the long id of button "myButtonName"
>>
>>
>> this will put the "new" behavior at the top of the two behaviors of the datagrid group. Obviously that will not work with editable fields.
>>
>> Kind regards
>> Bernd


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
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 <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Just one more note: I think this syntax would have been preferrable:

insert the script of button "myButton" {in front of | before} group "myDatagrid".

The parser would have to determine what the object was that was already in front of the datagrid, if there was any, and "plug in" the new bahavior between them. That would mean however that the behaviors for all objects would have to be saved with each object, but I suspect it has to do that now. Another forseeable advantage is that you could possibly have the ability to insert a script BEHIND an object as well, effectively having object based front and back scripts.

Not sure how handy this would be, but the syntax at least would be understandable.

Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
I believe I may have mispoken in this thread. Setting the behavior of an object does NOT insert the behavior script in FRONT of the object in the message path. It inserts it in BACK. I know this because I have a selectionChanged handler in both the object and it's behavior, and a breakpoint in each handler. The breakpoint is triggered in the object handler, and NOT in the behavior handler, as you might expect!

The front would have been handier because then you could leave a duplicate handler in both places, and then tested each by simply setting the behavior back and forth. As is, you have to REMOVE the object's handler before you can test the behavior! Oh well.

<Semi-but-not-reall-ranting>
So this means this syntax makes absolutely no sense whatsoever!

set the behavior of the behavior of the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors".

What *actually* happens is something like:

set the behavior of the long id of button "maingrids" of card "behaviors" to the behavior of group "dgSites"
set the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors"

but the second method won't work. So long as people doing nested behaviors are aware of this syntactical anomaly and the effect it has on the message path, all is well.
<end faux-rant>

Bob S
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Check out “before” and “after” in the dictionary (control structure). They allow what you are wanting.
On Jul 20, 2018, 1:44 PM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> I believe I may have mispoken in this thread. Setting the behavior of an object does NOT insert the behavior script in FRONT of the object in the message path. It inserts it in BACK. I know this because I have a selectionChanged handler in both the object and it's behavior, and a breakpoint in each handler. The breakpoint is triggered in the object handler, and NOT in the behavior handler, as you might expect!
>
> The front would have been handier because then you could leave a duplicate handler in both places, and then tested each by simply setting the behavior back and forth. As is, you have to REMOVE the object's handler before you can test the behavior! Oh well.
>
> <Semi-but-not-reall-ranting>
> So this means this syntax makes absolutely no sense whatsoever!
>
> set the behavior of the behavior of the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors".
>
> What *actually* happens is something like:
>
> set the behavior of the long id of button "maingrids" of card "behaviors" to the behavior of group "dgSites"
> set the behavior of group "dgSites" to the long id of button "maingrids" of card "behaviors"
>
> but the second method won't work. So long as people doing nested behaviors are aware of this syntactical anomaly and the effect it has on the message path, all is well.
> <end faux-rant>
>
> Bob S
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
I just realized why the method most useful for controlling scope won't
actually work.

For scoping, we want only some DGs to have custom behavior, so this
would seem most desirable:

       [ DataGrid ]
            |
            V
    [ Custom Behavior ]
            |
            V
[ Standard DG Behavior ]


Useful as that it for limiting scope, the problem is that much of the DG
code refers to objects within "me", and in this setup "me" refers to the
Custom Behavior object rather than the original DG group.  No subgroups,
fields, or anything else the DG expects to find are present in the
Custom Behavior object, resulting in script errors.

So the only way I can see this working at all is to toss scope control
out the door and swap the Custom Behavior to be the behavior object for
the Standard DG Behavior, as I believe Panos had suggested earlier.

Brian's suggestion of "before" and "after" handlers may help for some
aspects of message ordering, but all handlers in the Custom Behavior
object will affect all DGs once the Custom Behavior object is assigned
as the behavior for the global Standard DG Behavior.

At the risk of drifting toward OOPness, I wonder if this situation may
prompt us to consider some more refined method of having nested
controls, so that we can insert a custom behavior script in between a
global-scope behavior script and a subset of the controls it's assigned to.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
On 07/20/2018 11:43 AM, Bob Sneidar via use-livecode wrote:
> I believe I may have mispoken in this thread. Setting the behavior of an object does NOT insert the behavior script in FRONT of the object in the message path. It inserts it in BACK. I know this because I have a selectionChanged handler in both the object and it's behavior, and a breakpoint in each handler. The breakpoint is triggered in the object handler, and NOT in the behavior handler, as you might expect!

That's the way object-oriented programming works. You set the default
operation in the behavior script and then you can override it in the
object if needed. I think of behavior scripts more or less as private
backscripts of an object.

Otherwise, just follow Brian's suggestion.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
So far as I have been able to ascertain, "me" always refers to the original object, and NOT the behavior. As Jacques so helpfully pointed out, "this me" refers to the behavior's own script. So "me" might be thought of as a synonym for "the target" (insofar as I have been able to work it out).

I've been working with nested behaviors for a datagrid the better part of this day, since discovering how to do it, (thank you Bernd for your input on this) and the datagrid default behavior seems to be working as advertised, and behaving exactly as your diagram describes.  

Bob S


> On Jul 20, 2018, at 13:26 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> I just realized why the method most useful for controlling scope won't actually work.
>
> For scoping, we want only some DGs to have custom behavior, so this would seem most desirable:
>
>      [ DataGrid ]
>           |
>           V
>   [ Custom Behavior ]
>           |
>           V
> [ Standard DG Behavior ]
>
>
> Useful as that it for limiting scope, the problem is that much of the DG code refers to objects within "me", and in this setup "me" refers to the Custom Behavior object rather than the original DG group.  No subgroups, fields, or anything else the DG expects to find are present in the Custom Behavior object, resulting in script errors.
>
> So the only way I can see this working at all is to toss scope control out the door and swap the Custom Behavior to be the behavior object for the Standard DG Behavior, as I believe Panos had suggested earlier.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
Bob Sneidar wrote:
 > So far as I have been able to ascertain, "me" always refers to the
 > original object, and NOT the behavior. As Jacques so helpfully pointed
 > out, "this me" refers to the behavior's own script. So "me" might be
 > thought of as a synonym for "the target" (insofar as I have been able
 > to work it out).

Useful when that's what you want to do, but not something that can help
for overloading an existing behavior script which expects to able to
address controls relative to "me".


 > I've been working with nested behaviors for a datagrid the better part
 > of this day, since discovering how to do it, (thank you Bernd for your
 > input on this) and the datagrid default behavior seems to be working
 > as advertised, and behaving exactly as your diagram describes.

IIRC Bernd's suggestion was for global scope only, yes?  That is, it
swaps the positions of the two bottom scripts shown below, and affects
all DGs running in the session.

I can't think of another way to do it, but it would be nice to be able
to overload some DGs while leaving others alone.


 >> On Jul 20, 2018, at 13:26 , Richard Gaskin wrote:
 >>
 >> I just realized why the method most useful for controlling scope
won't actually work.
 >>
 >> For scoping, we want only some DGs to have custom behavior, so this
would seem most desirable:
 >>
 >>      [ DataGrid ]
 >>           |
 >>           V
 >>   [ Custom Behavior ]
 >>           |
 >>           V
 >> [ Standard DG Behavior ]
 >>
 >>
 >> Useful as that it for limiting scope, the problem is that much of the
 >> DG code refers to objects within "me", and in this setup "me" refers
 >> to the Custom Behavior object rather than the original DG group.  No
 >> subgroups, fields, or anything else the DG expects to find are
 >> present in the Custom Behavior object, resulting in script errors.
 >>
 >> So the only way I can see this working at all is to toss scope
 >> control out the door and swap the Custom Behavior to be the behavior
 >> object for the Standard DG Behavior, as I believe Panos had suggested
 >> earlier.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode


> On Jul 20, 2018, at 15:31 , Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> IIRC Bernd's suggestion was for global scope only, yes?  That is, it swaps the positions of the two bottom scripts shown below, and affects all DGs running in the session.

Actually no that is why I was saying the syntax was the complete opposite of what you'd expect. Bernd's solution actually produces the results you see in your diagram. The custom behavior is inserted between the datagrid and the default behavior. Odd, huh? But I've spent the better part of the afternoon updating each datagrid in my main form to use a one custom behavior with code common to each, while still preserving the default datagrid behavior. And, until I do that for each datagrid, it's own handlers are still in effect. I tested that by putting a breakpoint at the beginning of each selectionChanged handler, the behavior and the grid. Until I "inserted" the custom behavior, the datagrid verson of selectionChanged is what triggered.

> I can't think of another way to do it, but it would be nice to be able to overload some DGs while leaving others alone.

See above. :-)

Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Datagrids and Nested Behaviors

Clarence Martin via use-livecode
I just tried a simple test.  I created a stack, added a DG and a button.  I
used the example at the top of this thread to set the behavior.  I then
added another DG to the card.  Now when I double click on either DG, the
new behavior is used.  Is that what you are seeing and what you are
intending?

I saved the stack and quit / restarted LC.

I reopened the test stack.  Now, the new behavior is not applied.
I created a button to apply the behavior and did so (to make the test
easier to replicate).
Again, both DG's get the behavior.

I then created a new stack and added a DG.  It also responded to the added
behavior.  It seems like the scope of that statement is global to me.

On Fri, Jul 20, 2018 at 6:34 PM, Bob Sneidar via use-livecode <
[hidden email]> wrote:

>
>
> > On Jul 20, 2018, at 15:31 , Richard Gaskin via use-livecode <
> [hidden email]> wrote:
> >
> > IIRC Bernd's suggestion was for global scope only, yes?  That is, it
> swaps the positions of the two bottom scripts shown below, and affects all
> DGs running in the session.
>
> Actually no that is why I was saying the syntax was the complete opposite
> of what you'd expect. Bernd's solution actually produces the results you
> see in your diagram. The custom behavior is inserted between the datagrid
> and the default behavior. Odd, huh? But I've spent the better part of the
> afternoon updating each datagrid in my main form to use a one custom
> behavior with code common to each, while still preserving the default
> datagrid behavior. And, until I do that for each datagrid, it's own
> handlers are still in effect. I tested that by putting a breakpoint at the
> beginning of each selectionChanged handler, the behavior and the grid.
> Until I "inserted" the custom behavior, the datagrid verson of
> selectionChanged is what triggered.
>
> > I can't think of another way to do it, but it would be nice to be able
> to overload some DGs while leaving others alone.
>
> See above. :-)
>
> Bob S
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123