Re: Stylistic question.

Ah, okay, I think I understand. There's a bit to unpack here: 1. There is no direct communication between Navigator and the LC IDE toolbar. That means that the inspector triggered by the IDE toolbar will reflect whatever is selected. 2. Navigator *only* tries to change the current selection automa

Re: Stylistic question.

Yes that works. What doesn't work is selecting the card in the list, then clicking the Inspector button in the LC IDE toolbar. It's easier for me to do that because if I click another object in Navigator, the focus of the Inspector (Properties Editor) changes to the selected object. If I do the

Re: Stylistic question.

Can you be more specific? I tried selecting the card both in the live display and the specific card display, and then on the Properties "P" menu I selected Property Editor, Single Object Inspector, and Individual Object Inspectors, and it always came up showing the card. On Wed, Sep 7, 2022 at 3:0

Re: Stylistic question.

Hmm, I'll take a look. On Wed, Sep 7, 2022 at 3:04 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > While you are at it, selecting the card, then selecting the Inspector > button in the toolbar gets the stack properties, not the card properties. I > know I can right-click

Re: Stylistic question.

While you are at it, selecting the card, then selecting the Inspector button in the toolbar gets the stack properties, not the card properties. I know I can right-click and get the card properties, but if this is not the intended behavior I figured you'd want to know. Bob S > On Sep 7, 2022,

Re: Stylistic question.

Awesome good job. Bob S > On Sep 7, 2022, at 24:16 , Geoff Canyon via use-livecode > wrote: > > Okay, I figured it out. When Navigator is displaying whatever the contents > are of the current card (its default state) it syncs the selection with the > selected controls. This goes both ways, s

Re: Stylistic question.

Okay, I figured it out. When Navigator is displaying whatever the contents are of the current card (its default state) it syncs the selection with the selected controls. This goes both ways, so it's important not to get stuck in a loop: Navigator sets the selected controls, which in turn triggers N

Re: Stylistic question.

I went to Github, the latest version is 7.3 RC1 which is what I already had. Not sure where to look for the most recent version. Issue persists for me. Bob S > On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode > wrote: > > I'll have a look. > > Bob S > > > On Sep 5, 2022, at 19:11

Re: Stylistic question.

I'll have a look. Bob S On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: I will however ask for just

Re: Stylistic question.

Ha, I just realized that I responded to the Navigator part of the conversation without responding to the style part. When I wrote the "convert a control(s) to behaviors" code, I didn't think twice about what to apply it to or not -- I selected everything and converted it all. That was something lik

Re: Stylistic question.

Arriving late to the conversation. I never put code into buttons other that enough to cover messages. These will only have enough code in them to pass on the rest of the message. Eg on mouseUp pBtn btn_nameOfButtonMUp pBtn end mouseUp on mouseRelease btn_nameOfBtnMRel end mouseRelease

Re: Stylistic question.

On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > I will however ask for just one enhancement: If I am filtering the list and have an item or items selected, and then I clear the filter, it also clears the selection. It would be great if the sele

Re: Stylistic question.

On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > I will however ask for just one enhancement: If I am filtering the list > and have an item or items selected, and then I clear the filter, it also > clears the selection. It would be great if the

Re: Stylistic question.

by Navigator I was put off by Navigator at first, mainly because it was able to do a LOT, and I was looking for an easy answer to a complex problem: How to set properties for objects in a much more intuitive way that the LC Property Editor. Once I started using it however, I cannot imagine how

Re: Stylistic question.

Sorry for the late response, but thanks for the shoutout. I'll also mention that some time ago I put a fair bit of effort into enabling Navigator to behavior-ify any set of controls, automatically extracting their built-in code to script-only-stacks. I did it as part of the migration of Navigator t

Re: Stylistic question.

J. Landman Gay wrote: > Breakpoints work fine in the IDE. But script only stacks do not > retain them when remote debugging Breakpoints are a runtime-settable property, so those who enjoy C-flavored workflows with lots of tiny text files could save their breakpoints out to text files and have

Re: Stylistic question.

Red-dotting: A couple of things: 1) I don't use the SE very often, so I have not tried red-dotting before building. However, "BREAKPOINT" works. 2) Once you have the remote debugger up, you can red-dot all you like, and they will stick until the app closes 3) When I'm debugging (like I am, tonight)

Re: Stylistic question.

OIC I didn't grok you were talking about standalone apps. Bob S > On Jun 23, 2022, at 10:25 , J. Landman Gay via use-livecode > wrote: > > Breakpoints work fine in the IDE. But script only stacks do not retain them > when remote debugging, or at least they didn't for me. Are you talking abo

Re: Stylistic question.

Breakpoints work fine in the IDE. But script only stacks do not retain them when remote debugging, or at least they didn't for me. Are you talking about mobile apps? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On June 23, 2022 12:05:27

Re: Stylistic question.

Hi Jacqueline. I use script only stacks a LOT, and the red dot breakpoints are working for me. Try Clear All Breakpoints from the SE Debug menu (I think it will only clear breakpoints from open scripts though.) Also in the SE under the Breakpoints tab, you can uncheck all the existing breakpoint

Re: Stylistic question.

Something must have changed or you use a debugging method different from mine. Red dot breakpoints do not work in script only stacks because those stacks have no custom properties, which is where breakpoints are kept. I couldn't get scripted breakpoints to work either but I may have forgotten t

Re: Stylistic question.

J.: Not true on the remote debugging. Everything I write is for mobes. Literally everything. Except for the server code for the mobes, but comparatively speaking, there are many, many, many more lines in the mobe code than there is in the server code. All of these behaviors are in script-only-stack

Re: Stylistic question.

Well then Navigator is for you! If an object has a behavior and no script of it's own, it's color in the list is green. If it has a script but no behavior, it's color is blue. If it has both, it's purple. Simply double clicking an object opens it's behavior script if it has one, and it's native

Re: Stylistic question.

I find that too many behavior stacks make it difficult to keep track of where things are. But the primary downside is that script-only stacks don't work with remote debugging. That's a big drawback for me since most of my apps these days are for mobile. I do use behaviors quite a bit, but I put

Re: Stylistic question.

wupz. - i forgot the THEN's after each of the ELSE IF's too many languages on the same project swimming in my brain On Wed, Jun 22, 2022 at 9:46 AM Mike Kerner wrote: > For an example like a session during LCG, throwing everything into a > single script can make it easier to see everything, toge

Re: Stylistic question.

For an example like a session during LCG, throwing everything into a single script can make it easier to see everything, together, however, I absolutely, always, without exception, do this: 1) Every object that needs to do something gets its own handler, unless there is some reason to allow the beh

Re: Stylistic question.

On 20/06/2022 00:19, Bob Sneidar via use-livecode wrote: Well code shared commonly between multiple objects should generally be in an object shared by those objects. That can be the card, stack, behavior or front/back script. The script of a group as well. Absolutely. And the converse - code

Re: Stylistic question.

Well code shared commonly between multiple objects should generally be in an object shared by those objects. That can be the card, stack, behavior or front/back script. The script of a group as well. For example I have a behavior for all my datagrids. Each datagrid has a property called gridco

Re: Stylistic question.

One reason would be if you were trying to use behaviors so you could manage your code with a repository like Git. This would greatly reduce the number of behavior scripts that you would create. One app that work on has the code in the stack’s behavior script. Sent from my iPhone > On Jun 19,