You are welcome! Of course Bernd is the one who provided the key piece of
information.
I updated my GitHub repo with a README (trying to figure out how to do
them). So now when you go to the link, it will pull in the image and
provides links to this thread, the PR, and the individual scripts.
Thanks Brian. There IS no better development community in the world than this
one. This all began with Hypercard communities and their spirit of sharing and
mutual support. We seem to be the last bastion.
Bob S
> On Jul 24, 2018, at 16:31 , Brian Milby via use-livecode
> wrote:
>
> PR
Posted a demo stack showing a DG with a behavior button in front of the DG
library behavior.
https://github.com/bwmilby/lc-misc/tree/master/NestedDGBehavior
There is an image of the stack uploaded as well. The preOpenStack handler
will update the script (LC9) which will then be available until
PR submitted on Bug 21427.
https://github.com/livecode/livecode-ide/pull/1987
Since it is a full PR, I went ahead and switched over to using a script
local everywhere and initialize it when the DG is initialized. I also
looked for an object in the DG resource stack instead of hard coding the
Never mind Brian, it works. I had the behavior of the custom button set the the
behavior STACK and NOT the reDataGridLibrary stack button (now empty).
Once I got the behavior of the custom button set to the old behavior button,
the datagrid now works! You guys are freaking geniuses!
Bob S
I’ll put something together tonight. The code in the library has to be updated
before opening a card with a DG that has the adjusted behavior chain. I have an
idea on how to do it in script, but need to test it out to verify it will work.
On Jul 24, 2018, 9:54 AM -0500, Bob Sneidar via
I did so. I get this when opening my test stack:
91,260,123
62,260,123
77,260,123
456,260,57
534,260,123
253,260,123
241,236,1,_Initialize
353,0,0,stack "/Applications/LiveCode Community 9.0.1 (rc
Brian
That is a nice modification, makes it faster and is still only in one place.
>I also noticed that there are extra "stack" references in the code (stack
>_ResourceStack instead of just _ResourceStack 4/10 uses).
to my surprise both versions work.
Kind regards
Bernd
Brian Milby via
Here is my slight modification to the suggestion:
local sResourceStack
private function _ResourceStack
local theStack, theCharNo
if sResourceStack is empty then
put the behavior of me into theStack
repeat
if trueWord -1 of theStack is "revDataGridLibrary" or theStack
On Mon, Jul 23, 2018 at 4:51 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Thanks for looking into this all. Leave it to me to attempt some edge case
> scenario. I'm curious how Trevor handles this in his levure framework.
> There's no way I can see to move current
What OS are you using? It will be inside the IDE, but will get copied into your
app as well. You will probably need admin rights to edit. I would do it in an
external editor too.
It probably would be an enhancement request (therefore 9.1), but I would be
happy to submit a PR against a BZ
I found and made a copy of the datagrid library stack on my desktop. I still
cannot save the modification you proposed to the script of the datagrid button
in this stack. It says it can't open stack script file.
Well my workaround is functional, so I'm sticking with that. If the devs want
to
I tried this, I apparently don't have permission to save the file once edited.
It's probably in the Livecode APP bundle. I'll poke around and test this later.
Bob S
> On Jul 23, 2018, at 15:22 , Niggemann, Bernd via use-livecode
> wrote:
>
> my solution would be to change private function
my solution would be to change private function _ResourceStack of stack
RevDataGridLibraryBehaviorsDataGridButtonBehavior to
private function _ResourceStack
local theStack, theCharNo
put the behavior of me into theStack
repeat
if trueWord - 1 of theStack is "revDataGridLibrary" or
Thanks for looking into this all. Leave it to me to attempt some edge case
scenario. I'm curious how Trevor handles this in his levure framework. There's
no way I can see to move current custom code to a stack only script for
datagrids.
Bob S
> On Jul 23, 2018, at 14:01 , Brian Milby via
So that is something that could be fixed pretty easily. I’m thinking a script
local to store the value which will offset the additional work to figure it out
the first time.
Logic would be to check for some key object and if not found then move up the
behavior chain a level and look. Could
The problem Bob Sneidar ran into by changing the order of the behaviors of a
dataGrid is due to the initialization process of the dataGrid at start-up.
The behavior looks for a resourceStack by means of this handler.
private function _ResourceStack
local theStack, theCharNo
put the
The Datagrid no longer behaves as such. SelectionChanged never gets triggered.
Data doesn't populate. In short, none of the custom props messages seem to
arrive at the datagrid library.
Bob S
> On Jul 23, 2018, at 08:29 , Richard Gaskin via use-livecode
> wrote:
>
> Was your request
Bob Sneidar wrote:
> With a clearer head I have discovered that indeed setting the behavior
> in the way prescribed sets it GLOBALLY for ALL grids! That will not do
> for my purposes, because the grids in my substacks operate a bit
> differently than the one in the mainstack.
>
> Well my
Hi all.
With a clearer head I have discovered that indeed setting the behavior in the
way prescribed sets it GLOBALLY for ALL grids! That will not do for my
purposes, because the grids in my substacks operate a bit differently than the
one in the mainstack.
Well my workaround before was to
Bob,
I also found that changing the behavior of group "dataGrid x" does not stick
and after restart you have to set it again.
However if you want to use the convenience of a behavior you could set in your
case as far as user interaction via doubleMouseUp is concerned you could set
the
@Richard,
That is precisely what I saw when I did my test. (And DG3 was in a
different stack.)
I tried manually replacing the old button with one in the stack and that
completely broke the DG.
@Bob
Another option to get script in front of the library would be to set the
script of:
button id 1005
Bob Sneidar wrote:
> This is NOT the current normal behavior.
>
>> On Jul 20, 2018, at 17:13 , Richard Gaskin wrote:
>>
>> This is a normal setup:
>>
>> [ DataGrid ]
>> |
>> V
>> [ Standard DG Behavior ]
>
>
> THIS is:
>
>> [ DataGrid ]
>> |
>> V
It is not a bug. You can't save a behavior on a script only stack, they
much be added after they loaded. There is a new syntax to make it
automatic, but that wouldn't help here.
In the IDE, enable "Show IDE stacks in lists", open the Project Browser.
Find
belay all that. Apparently I have to get the behavior of the behavior of
the ehavior of the datagrid. THAT seems to correctly return the id of the
custom button. But the datagrids do not seem to work after a close and reopen
of the stack, unless I use this workaround. So there is still
Okay my workaround is to have a custom property with the name of all the
datagrids on a card in a custom property. Then in the openStack handler of the
card I have:
setMainCardBehaviors
In the same script I have:
on setMainCardBehaviors
put the long id of me into tParentCard
put the
I should have said, after closing the stack, and quitting/relaunching Livecode.
Bob S
> On Jul 20, 2018, at 18:41 , Bob Sneidar via use-livecode
> wrote:
>
> It seems that even though I save the stack after setting this behavior,
> Livecode RESETS THE DATAGRID BEHAVIOR TO THE DEFAULT!
OKAY HUGE BUG ALERT!!!
It seems that even though I save the stack after setting this behavior,
Livecode RESETS THE DATAGRID BEHAVIOR TO THE DEFAULT!
What the EFF? Of course I can get around it with a custom openCard handler that
resets them, (and in the words of Malthesar when discovering
This is NOT the current normal behavior.
> On Jul 20, 2018, at 17:13 , Richard Gaskin via use-livecode
> wrote:
>
> This is a normal setup:
>
> [ DataGrid ]
> |
> V
> [ Standard DG Behavior ]
THIS is:
> [ DataGrid ]
> |
> V
> [ Old behavior
The first "behavior" is a reference to the script of the button to be inserted.
The other two are because LC moved the datagrid behavior to a script only file,
but left the old button (now empty) in the message path. I was thinking that if
you inserted a behavior after THAT button but BEFORE
There are three objects including the custom behavior button.
Bob S
> On Jul 20, 2018, at 17:13 , Richard Gaskin via use-livecode
> wrote:
>
> On further consideration, there's something even odder in my understanding of
> Bernd's script. Let me rewrite it with line breaks for clarity:
>
Bob Sneidar wrote:
>> On Jul 20, 2018, at 15:31 , Richard Gaskin 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
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
> On Jul 20, 2018, at 15:31 , Richard Gaskin via use-livecode
> 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
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
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).
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
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
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
, wrote:
> I believe I may have mispoken in this thread. Setting the behavior of an
> object does NOT insert the behavior script in
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
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
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
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
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
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
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 <
use-livecode@lists.runrev.com> wrote:
> Correction
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
> wrote:
>
> The only bugaboo will be when I send selectionChanged. The target will not be
> a control of the datagrid,
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
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
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
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 be
51 matches
Mail list logo
