LiveCode Forums.

richmond62 , thanks a lot ! you put me in the right direction

the actual command I needed to open it was

open stack "my_stack[dot]livecodescript"

thanks again, I wish live code errors were a bit more helpful:
for the command
open stack "lib_stack"

the error:
stack "main": execution error at line 2 (Handler: error in statement), char 1

doesn't tell me much ...
btw, it seems that if the stack is already opened - it doesn't need the livecodescript - if it isn't (which is the 'normal' case) it doesn't
but thanks again

OK . . . all very well and good . . . But . . .

Here I am with my main stack, which is 'just' a light-and-frothy front-end for my 'main thing', and I want to
call the script-only stack . . . now:

1. Can I open the stack like an other type of stack and then use a 'do' or a 'send' to get at a script within it?

2. Or?

Having been messing around with LiveCode for about 20 years my experience of error messages
is that 90% of them mean:

'get on the Use-list or the Forums and start asking questions' as, otherwise, they make very little sense at all.

arrrggg
I've been around for 30 years in multiple environments - I am on this one cause my son took a course and I am doing my best trying to help out.
it's really frustrating, but thanks a lot for your help

I REALLY like the idea of live code - but have many issues with the envirment - never mind this though. you've helped a lot, I'll take it from here.

thanks again

You will find that if you post a question on the Use-List or the Forums you will,
generally, get a fairly swift and helpful response
as LiveCode has a vibrant and healthy user base.

LiveCode errors are often more helpful than that. Next time you see it could you post a screen shot so we can get a better idea where the error reporting is coming from?

As for the error itself, I suspect the issue is eith8 that the script can't find the stack, or that the script-only stack is missing its "script" declaration on line 1.

How do script-only stacks relate to theming?

Main stack -> SOS
SOS's are always behaviors, so you could also call them "behavior stacks". You can also stick them manually in the message path if you like. SOS's can also have other SOS's as their behaviors.

theming
maybe i misunderstood. I was reading a comment from someone that was complaining about not liking the interface of using an external editor. I took that to mean theming/syntax coloring/indenting/etc.

So: I have a main stack called "mStack" and a substack that is a script-only stack called "scriptSTAK'.

Stack "scriptSTAK" has this script:
Stack "mStack" has a button "Call Script-Only stack" containing this:
AND, Yer . . . it puts "Here's a signal from a script-only stack!" into the MessageBox.

Somehow I cannot quite understand what all the song and dance is about, about
these much-vaunted script-only stacks [make me think of Visual BASIC 5 - a bad, bad patch in my life]
when that can all be in a button or in a card or in a stack.

-
Cooperman: who created the drag-and-drop design for the user interface of Visual Basic.

Must be a slow day over there for you my friend heh.

I actually liked VB 5 to 6.x, especially in conjunction with Fox Pro, whenever I had to do something 'Windowsy' in my pre-Delphi days. I found it quick to work in, easy to use, well formed IDE, decent text editing capabilities, etc etc. In fact, I felt right at home moving from that to Delphi, and subsequently to RealBasic from there.

I did *not* care as much for the transition to dot.nuts.

Many folks overthink SoSes. I've seen experienced devs get thrown by them. Not sure why, but I've seen it a lot.

There is only one thing to know to use them well:

A stack is a stack is a stack. They all behave the same.

The only difference between a SoS and any other stack is the STORAGE FORMAT on disk. That's it. Once opened in memory a stack is a stack is a stack.

If anything seems confusing about a SoS just use a regular stack and see if the problem becomes more easily solvable.

Too many are using them when they're not needed. They're useful when using GitHub or other VCS designed for other languages that don't let you embed code in UI stuff, and they're sometimes useful for working with external text editors in a non-modal way, or in server contexts where you want to edit in Terminal.

If none of those apply to your work, there's likely no benefit at all to using the script-only option for stack storage.

FourthWorld wrote: Mon Apr 13, 2020 8:09 pm There is only one thing to know to use them well:

A stack is a stack is a stack. They all behave the same.

Well, you *can* put a stack only script into a field neatly, where a regular stack comes out...funny due to it's binary nature.

Why would that make a difference? Well, if you created your own script editor, you could neatly use it to edit s.o.s. stacks all day long.

You can put the script of any object into a field.

If you're making a script editor there's no need to limit it to SoSes.

FourthWorld wrote: Mon Apr 13, 2020 9:43 pm You can put the script of any object into a field.

Yes, but you can't reliably work with a binary stack in a field. A script only stack you can, easily, and easily edit it is all I was pointing out.

I am still working out assigning scripts to objects in the regular stack myself, I'm sure it is old hat to everyone else though Bear with me, I'll get there eventually heh.