Re: Behaviors

I'll admit it's not very intuitive, but: In Navigator, right-click any button. On the context menu, select Copy > Objects. Navigate to any control or card, stack, etc. Bookmarks are fine for this as well. Right-click any other control. On the context menu, select Set Copied Btn as Behavior. On Th

Re: Behaviors

polygrid the api is similar, but they also have some nice additional features. i have ripped all my dg's and replaced them with pg's. now, if you're using custom templates, have a look at the pl - polyList. On Thu, Aug 24, 2023 at 2:12 PM Bob Sneidar via use-livecode wrote: > > Ah thanks for that

Re: Behaviors

Ah thanks for that. Yes, I knew how to nest behaviors for datagrids, but I never use the Project Browser because of issues I had many years ago. I may have another look. What is a “pg”? I make extensive use of Datagrid properties, and whatever I might replace them with needs to provide ALL the

Re: Behaviors

i'm pretty sure you can set a dg's behavior. then you would set the behavior of that behavior to the button behavior (button id 1005 of stack "revDataGridLibrary"), OR you can include THAT script, separately, set that as the behavior, and modify it (but, what you should really do is remove your dg'

Re: Behaviors

There is also the Advanced button in the property inspector (looks like one large gear with two smaller ones) where you can type the behavior, and also has the target icon. Also, you shouldn’t have to do that every time. Once should be enough if you save the stack afterwards. I note that Datag

Re: Behaviors

I, too, have discovered the target icon to the right of the behavior object field in the property inspector. Alas, using that that I see only buttons on the current card (and stacks). I don’t see a way to navigate to a different card and select a button there. I might have missed it. — Dar > On

Re: Behaviors

you probably know this: in the property inspector, there's a panel for behavior, so you can just select the behavior from a menu button, without having to type it On Tue, Aug 22, 2023 at 1:37 PM Dar Scott via use-livecode wrote: > > I figured out how to do it in the IDE. I needed to include “of s

Re: Behaviors

I figured out how to do it in the IDE. I needed to include “of stack” in the reference. — Dar > On Aug 22, 2023, at 11:09 AM, Alex Tweedly via use-livecode > wrote: > > Not sure how it works in the IDE - seems a problem because it only presents > button in the current stack. > > So I do it a

Re: Behaviors

Not sure how it works in the IDE - seems a problem because it only presents button in the current stack. So I do it all in preOpen... scripts, doing something like set the behavior of fld "F" of grp tmpName to the long id of button "RichTextFieldBehaviour" of \ card "Behaviours" of st

Re: Behaviors and scripts and a new handler structure...

Hi Bob, If you have a bit of time, could you tell us a bit more about how? Thanks, Mark > On Apr 2, 2021, at 12:42 AM, Bob Sneidar via use-livecode > wrote: > > I have already implemented this with the help of others, for Datagrids. I > think it works already for other things. > > Bob S >

Re: Behaviors and scripts and a new handler structure...

I have already implemented this with the help of others, for Datagrids. I think it works already for other things. Bob S > On Apr 1, 2021, at 12:51 , Paul Dupuis via use-livecode > wrote: > > I have increasingly been using behaviors in my applications where it makes > sense to assign a scr

Re: Behaviors not honoring script local variables??

Not only that, I think I overthought this. All I really need to do is retrieve the array and then use the array elements instead of the variables. It all started when I began using behaviors and discovered that a behavior does not have access to a scripts own constants. This was a way for me to

Re: Behaviors not honoring script local variables??

You know you are right. I just noticed that. That syntax of mine should not have even worked LOL! Talk about a forgiving interpreter! Bob S > On Jun 26, 2018, at 23:25 , Dick Kriesel via use-livecode > wrote: > >> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode >> wrote: >> ...

Re: Behaviors not honoring script local variables??

> On Jun 26, 2018, at 1:13 PM, Bob Sneidar via use-livecode > wrote: > ... > do "put " & quote & aStackConstants [tConstant] & quote & " into " & > tConstant Hi, Bob. If you wanted simpler code, that could be just do "put aStackConstants[ tConstant ] into " & tConstant — Dick _

Re: Behaviors not honoring script local variables??

Yes that was my problem. Hovering or viewing the variable in the debugger while getStackConstants was running would show the script local variable values being updated, but as soon as the handler exited, they were all empty again, meaning the handler was not updating the script local variables,

Re: Behaviors not honoring script local variables??

i remember debugging a local script in a datagrid behavior and having to figure out which index it was working on.new window would work the same but you'd still need to give yourself that piece of data that will tell you which one it is. another thing i keep on forgetting in v9 is when you ho

Re: Behaviors not honoring script local variables??

Hmmm... something you said set me to thinking. Suppose I already had the instance of a behavior opened in the script editor with a breakpoint set. I then execute a handler in another object with the same behavior. Which instance is the script editor going to show me?? Ideally, it should open a n

Re: Behaviors not honoring script local variables??

Yes, well for whatever reason it's working now. I didn't change anything, I just quit and relaunched. It may be some kind of topstack issue where the topstack is changing and I don't know it's happening. Bob S > On Jun 26, 2018, at 13:44 , Tom Glod via use-livecode > wrote: > > h.. ...

Re: Behaviors not honoring script local variables??

h.. look inside the preferences to the script editor. try to see if "variable preservation" helps you..i think its an engine property. On Tue, Jun 26, 2018 at 4:41 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > > > > On Jun 26, 2018, at 13:30 , J. Landman

Re: Behaviors not honoring script local variables??

yup a feature that makes lc driven datagrid possible. :) and many other things. On Tue, Jun 26, 2018 at 4:30 PM, J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > Every instance of a behavior maintains its own separate variable values. > This is a feature. Globals are

Re: Behaviors not honoring script local variables??

> On Jun 26, 2018, at 13:30 , J. Landman Gay via use-livecode > wrote: > > Every instance of a behavior maintains its own separate variable values. This > is a feature. Globals are the solution if you want them to share the values. > I don't want to share the variables. I want them to be l

Re: Behaviors not honoring script local variables??

Every instance of a behavior maintains its own separate variable values. This is a feature. Globals are the solution if you want them to share the values. On 6/26/18 3:19 PM, Bob Sneidar via use-livecode wrote: Works with globals, but not script locals. Bob S On Jun 26, 2018, at 13:13 , Bo

Re: Behaviors not honoring script local variables??

Works with globals, but not script locals. Bob S > On Jun 26, 2018, at 13:13 , Bob Sneidar via use-livecode > wrote: > > Hi all. > > I have a behavior script with a handler: > > local cTableName, cDGName, cPriKey, cAltTable1 > > on getStackConstants pParentStack > -- retrieve stack con

Re: Behaviors

Hi Devin. That actually works a peach, thanks. I'm excited about going to behaviors, as I have a LOT of identical code in my app and this is going to streamling everything a great deal. Bob S > On Sep 18, 2017, at 16:23 , Devin Asay via use-livecode > wrote: > > Sorry, I should have said “

Re: Behaviors

Sorry, I should have said “Use 'before menuPick' or 'after menuPick' instead of ‘on menuPick’. On Sep 18, 2017, at 5:21 PM, Devin Asay via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Bob, Maybe the best way to do this is to use the before or after control structure in the beha

Re: Behaviors

Bob, Maybe the best way to do this is to use the before or after control structure in the behavior, rather than the menuPick. before menuPick pItem # do common behavior stuff here end menuPick That leaves the menuPick handler unencumbered in the actual object. Devin On Sep 18, 2017, at 5:14

Re: Behaviors and the message path

>> Mark wrote: >> So... Either I'm not crazy or I've got company. > > Bob wrote: > 2 other options. Neither of you is crazy. Both of you are crazy. These are not 'other' options!? Both cases are already included in the listing of Mark. Or is it a typo, did you mean "2 other options:"? _

Re: Behaviors and the message path

2 other options. Neither of you is crazy. Both of you are crazy. What do they teach children in logic classes these days?? ;-) Bob S On Dec 9, 2016, at 18:25 , Mark Wieder mailto:ahsoftw...@sonic.net>> wrote: I think of them as private backscripts, available only the object to which they are

Re: Behaviors and the message path

Thanks for taking the time to explain this Mark. After I thought about it for awhile I expected that this would be your answer and again I’m very pleased with how you’ve implemented the behavior feature. Tim Bleiler, Ph.D. Instructional Designer, HSIT University at Buffalo > On Dec 12, 2016, a

Re: Behaviors and the message path

On 2016-12-09 19:44, Bleiler, Timothy wrote: I still have one question though. Given the part of your answer I quoted above, why does the “pass” control structure trigger handlers along the behavior chain rather than skipping over them and going to the next object in the ownership chain? Becaus

Re: Behaviors and the message path

Actually I got the idea from you. But so far it seems to hold. Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 9, 2016 8:27:18 PM Mark Wieder wrote: On 12/09/2016 03:15 PM, J. Landman Gay wrote: On

Re: Behaviors and the message path

On 12/09/2016 03:15 PM, J. Landman Gay wrote: On 12/9/16 4:47 PM, mwieder wrote: But at any rate, I believe conflating "extending" a script with "concatenation" is the wrong way to think about behaviors. I think of them as private backscripts, available only the object to which they are attach

Re: Behaviors and the message path

On 12/9/16 4:47 PM, mwieder wrote: But at any rate, I believe conflating "extending" a script with "concatenation" is the wrong way to think about behaviors. I think of them as private backscripts, available only the object to which they are attached. If the behavior doesn't catch a messages,

Re: Behaviors and the message path

Tim Bleiler wrote > Maybe I didn’t explain what I’m actually doing correctly or we’re just > doing something different, but after I assign the behavior I do NOT get > the same result. Er...yes, you're right. That's what happens when I try to multitask and type without thinking. The other project I

RE: Behaviors and the message path

mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of J. Landman Gay Sent: Friday, December 09, 2016 3:22 PM To: How to use LiveCode Subject: Re: Behaviors and the message path On 12/9/16 1:49 PM, mwieder wrote: > ...and I want to echo your appreciation of Mr. Waddingham's > ste

Re: Behaviors and the message path

> On Dec 9, 2016, at 2:44 PM, mwieder wrote: > > I think it's wrong to consider behavior scripts as concatenated onto the end > of a script. If you rather think of the behavior script as a library or > backscript, then the message path becomes a little clearer. Thinking of behaviors as a libra

Re: Behaviors and the message path

On 12/9/16 1:49 PM, mwieder wrote: ...and I want to echo your appreciation of Mr. Waddingham's stewardship of the xtalk legacy. I have argued (and will continue to do so) with him about fine points of interpretation and future direction of the language, but I always appreciate his constant conser

Re: Behaviors and the message path

...and I want to echo your appreciation of Mr. Waddingham's stewardship of the xtalk legacy. I have argued (and will continue to do so) with him about fine points of interpretation and future direction of the language, but I always appreciate his constant conservative approach to making changes and

Re: Behaviors and the message path

Tim- I think it's wrong to consider behavior scripts as concatenated onto the end of a script. If you rather think of the behavior script as a library or backscript, then the message path becomes a little clearer. In your example 2, the message "you are in Script 3" appears because that instance o

Re: Behaviors and the message path

On Dec 9, 2016, at 12:56 PM, Mark Waddingham mailto:m...@livecode.com>> wrote: Rule (2) preserves this semantic for behaviors and, indeed, codifies the fact that behaviors aren't really objects - they are script extensions (for want of a better term). Thank you Mark, your explanation is very

Re: Behaviors and the message path

On 2016-12-08 21:23, Bleiler, Timothy wrote: I’m curious about what appears to me to be a confusing aspect of the implementation of behaviors. In short, behaviors have characteristics of an isolated, local extension of the message path AND characteristics of a concatenation of the parent control’

Re: Behaviors and the message path

On Dec 8, 2016, at 10:31 PM, Mark Wieder mailto:ahsoftw...@sonic.net>> wrote: I think the best explanation of the message path is still Richard Gaskin's chart and web page. Although I have to give props to Dar Scott for his message primer as well. I tend to think of behavior scripts (and I know

Re: Behaviors and the message path

On 12/08/2016 04:40 PM, Bleiler, Timothy wrote: Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I agree, there are terrific benefits with the current implementation of the behavior feature. My main concern was insuring that what I observed was intended. If

Re: Behaviors and the message path

I think I need an example, because I'm not understanding the problem that you're having with the currentbehavior On Thu, Dec 8, 2016 at 7:40 PM, Bleiler, Timothy wrote: > > On Dec 8, 2016, at 5:09 PM, mwieder wrote: > > > > I don't see these as anomalies or inconsistencies, but as features

Re: Behaviors and the message path

> On Dec 8, 2016, at 5:09 PM, mwieder wrote: > > I don't see these as anomalies or inconsistencies, but as features that help > implement proper object-oriented behavior. Tim- what "problems" do you see > with the way this is implemented? Am I missing something? Thanks Mark. I probably shouldn’

RE: Behaviors and the message path

(Different Mark here, but...) Yes, that's by design and explicitly to allow for overriding. It's *very* useful, for example, for setting up default behavior in a behavior script and then selectively overriding that in some, but not all, the objects that use that behavior script. The issue of scri

RE: Behaviors and the message path

> Tim Bleiler, Ph.D. wrote >if the same handler name is present in the behavior script and the parent >script, the parent script handler is >the one that runs. Wow! This is good to know. This could be very handy overriding a behavior handler for a specific control. As you said, there seems to be

Re: Behaviors not behaving

On Mon, Dec 1, 2014 at 12:13 PM, Peter Haworth wrote: > Good news is that your trick of resetting the behaviors to themselves > fixed the problem! And it's really fast. Thanks for that. I guess I spoke too soon. Although the fix does work, controls with linked behaviors are now misbehaving.

Re: Behaviors not behaving

Hi Scott, I stepped through my initialization code and it all goes through to the end no matter which stack I open first. Good news is that your trick of resetting the behaviors to themselves fixed the problem! And it's really fast. Thanks for that. I'm still not understanding why that should be

Re: Behaviors not behaving

Hi Ralph, Might be a related issue but in this case, I'm opening stacks from within the IDE not by double clicking them in the Finder. Pete lcSQL Software Home of lcStackBrowser and SQLiteAdmin

RE: Behaviors not behaving

Peter, I run into this when I double click on a stack to open the IDE. My library stacks are not yet fully loaded and calls to them fail. The trick for me is to load the IDE then load the stack I'm working on. This only applies to the library stacks in the MyLiveCode/Plugins folder when running in

Re: Behaviors not behaving

>From what you describe, there may be a timing thing going on as you suggest >(controls opening before their behaviors are available). You say your plugin >“creates an application stack file” so another thing to check is correct >behavior references applied to your controls. If your behaviors

Re: Behaviors

Thanks Ralph, I'll check into that. This happens in a plugin so there won't ever be a standalone to check. And of course it's in one that is about to go into beta proving yet again that those little buglets just bide their time before surfacing at a time that guarantees they cause the most frustr

Re: Behaviors

Thanks Monte. Richard posted the link to the QCC report for the resolveBehaviors enhancement and Mark's subsequent thoughts on it. I don't think anything about the behaviors is being changed. That's born out by the fact that if I quit LC and re-run with the same stack, everything works again. T

RE: Behaviors

Peter, If this only happens in the IDE it might be related to bug http://quality.runrev.com/show_bug.cgi?id=12508 I couldn't nail this one down until today. I created a recipe for support. Hanson reproduced it in the lab. Ralph DiMola IT Director Evergreen Information Services rdim...@everg

Re: Behaviors

On 25 Sep 2014, at 10:06 am, Peter Haworth wrote: > The behaviors all work fine when the stack is first opened, > Then, after some time using the stack and adding new controls which refer > to the behaviors, the behaviors suddenly stop being resolved. Hmm... behaviors are stored as an id and a

Re: Behaviors

Hi Richard, Our posts crossed, thanks for the QCC reference. Your QCC report describes a situation very similar to mine - using a library stack to hold the behaviors. However, my behaviors start off behaving themselves and only start misbehaving at some point later in using the stack. I think pe

Re: Behaviors

Thanks Scott. I've come across that situation before but this is different. The behaviors all work fine when the stack is first opened, Then, after some time using the stack and adding new controls which refer to the behaviors, the behaviors suddenly stop being resolved. I'd file a QCC report b

Re: Behaviors

Peter Haworth wrote: Anyone else's applications' guilty of bad behavior like this and if so is there a way to correct their behavior? May be relevant: Behavior resolution is too strict and is confusing http://quality.runrev.com/show_bug.cgi?id=8993 The only workaround I've used is to walk thr

Re: Behaviors

Hi Pete: Not sure if this is true in your case, but one reason why this can sometimes happen is if, for whatever reason, a control that has a behavior assigned to it gets opened before is associated behavior is present in memory. You might check if there is any delay occurring when launching the