Lessons - Learned expanding list

[mcelvain]

Noo-bie lessons-learned as of 061923:

- store your initial install disk image in a safe place; dunno about license file; probably
- be careful adding bg scripts containing [(pre)open/close-stack] handlers
- add a ‘date modified’ to functions created
- … well maybe handlers, too
- keep the phone number of your retinal specialist handy until default debugger text displays are customizable

[jacque]

I'm not sure it was your background script that caused the problem. I'd vote for the LC bug that doesn't know what the proper topstack is.

[mcelvain]

Jacque, I have a bad habit of editing multiple scripts at once using LC’s debugger’s directory capabilities.

The result is that the order of windows open is not consistent with the order of stacks.

I am able to edit the script of the bottom stack without bringing it to the “top.”

… maybe…

At least I think that’s correct.

If so, then LC would have to distinguish between a stack’s window and its currently-edited script window.

Would this contribute to the “bug” you referenced?

[jacque]

Jacque, I have a bad habit of editing multiple scripts at once using LC’s debugger’s directory capabilities.

I do that routinely, it's pretty common I think.

The result is that the order of windows open is not consistent with the order of stacks.

I am able to edit the script of the bottom stack without bringing it to the “top.”

… maybe…

At least I think that’s correct.

Yes, that's right.

If so, then LC would have to distinguish between a stack’s window and its currently-edited script window.

Would this contribute to the “bug” you referenced?

Maybe, I'm not sure. Since I can't reproduce the problem reliably it's hard to say what causes it. I have two different projects that each work with many stacks at once. That may be why I see the issue more often than some. The script editor does a good job of keeping track of the object you're editing because it uses the long name of the object to specifically identify it. But when I'm running the stacks and using the message box, the IDE can get very confused. It can click at a place not related to the mouse position, the message box doesn't identify the topstack correctly, it often doesn't know which card I'm working on. The only fix is to quit and restart LC. I just had to do that not 5 minutes ago.

So it seems to me the main problem is with the message box, which kind of loses its mind. The longer I try to work with the IDE when the problem occurs, the worse things get; keyboard shortcuts fail, scripts won't open, just now the edit tool was clicking instead of selecting. If I had a recipe I'd report it but I haven't found one yet.

[mcelvain]

You’re correct, Jacque, that the mb has been the source of handlers which had covered it with the infamous “Something” dialog box.

And, yes, I’ve noticed that the mb quite often doesn’t recognize the last stack I clicked.

LC is a much busier platform than SC; lots of messaging running under the hood that seem to work better before my computer heats up.

It did not occur to me to check the temp of the processor when bad events occurred.

—

For example, if I type a quote before a string, getting two instead, the quickest workaround is to select the string than drag between the quotes.

But the temperature of my motherboard seems to correspond to the ticks I have to wait until I attempt to move the string.

[ I assume there is a preference box that would also negate the double-quote problem]

?!

[dunbarx]

Doesn't all this stuff about the poor message box derive from the fact that "Everything is just a stack"?

That simple concept is one of the most endearing attributes of LiveCode. But in the case of the MB, which, when one is trying to navigate and work, both lurks around and insinuates itself everywhere like an uninvited in-law, I agree it ought to have a property to isolate it from the main suite of open stacks.

Or just never "be" there at all. Does anyone ever want to have the MB be the current topStack?

Craig

[jacque]

For example, if I type a quote before a string, getting two instead, the quickest workaround is to select the string than drag between the quotes.

This is an extension of the script editor option where sets of characters are automatically added (brackets, parentheses, quotation marks, etc.) You can turn off the option from the script editor menu: Edit -> Options -> Bracket completion.

The message box used to be exempt from those options but recently has started using whatever you've chosen for the script editor itself. I could do without that, TBH.

Craig: I can't think of any time I'd want the message box to be the topstack, and it never used to be. This is a fairly recent bug in the message box. Somewhere in there I think LC omitted a "set the defaultstack to the topstack" command.

[dunbarx]

Jacque,

It might be difficult to give the MB special status, given that it is just a stack. It has to have the ability to be easily brought in "front", but not really "there" among its peers. But I bet it would make a lot of little odd annoyances go away if the team could do that.

Craig

[stam]

The message box used to be exempt from those options but recently has started using whatever you've chosen for the script editor itself. I could do without that, TBH.

Doesn't quite do that for me - single line msgBox has no bracket completion but multiline does (I guess that's because my SE does). Kinda makes sense to me - for 1-line scripts where you don't need this it's not there, otherwise it uses what you're used to.

OTOH you could argue about inconsistencies...

Bracket and quote completion used to bug me a lot when I first started using lC - but it's grown on me and I now miss it anytime I'm in other environments. I guess I'm just lazy

[richmond62]

I stick to the single line MB, as the multiline MB has just mucked things up, made me force quit LC, stamp around the room swearing, and so forth.

With OS such as Debian xfce, where the MB is functionally useless (cannot get it to recieve focus), I just create nonce buttons to run scripts.

[jacque]

Doesn't quite do that for me - single line msgBox has no bracket completion but multiline does

You're right. No wonder I thought the feature came and went on a whim.

Bracket and quote completion used to bug me a lot when I first started using lC - but it's grown on me and I now miss it anytime I'm in other environments.

The convenience is great but I resent having to skip over or delete the second quote or bracket if I'm editing a section that already has one. But in general, it's good so I keep it on. In fact, after getting used to it I set up BBEdit to do the same thing.

[mwieder]

I think part of the reason for the stack target confusion is that much of the legacy IDE code still refers to stacks by name rather than by absolute path. Sometimes this results in the annoying "another stack by this name" dialog, but I think other times it may contribute to the loss of focus to the default stack or the topstack or "this" stack or "me".

[richmond62]

Or on Xubuntu and Debian xfce the inability to focus on the message box?

Although, to be honest I don't understand the advantage of absolute paths rather than names.

[mwieder]

Although, to be honest I don't understand the advantage of absolute paths rather than names.

Here's one:

Make a new stack (default name = "Untitled 1")
save it.
Find another stack previously saved to your hard disk (Note: filename may have no relation to stack name)
Oops - maybe it got saved with the default name earlier.
Or maybe you receive a stack from someone else - no telling what the actual stack name is.

Now you get the "another stack with the same name" dialog with options Cancel, Purge, Save.

If the stacks were referred to by pathname this could be alleviated.
And you wouldn't have to mull over the difference between Cancel and Purge or worry about what Save would do.

[richmond62]

Thank you, Mark, for an explanation that is a model of clarity.