Why Script-only stacks?

[foosmaster]

the revert is cool - I'll give it a shot asap
I think at this point of time as far as IDEs go, we've come to expect certain things such as:
"it seem that the stack (source?) has been changed , would you like to reload it ?" if not have it auto relaod, even notepad++ does that for you ...

still haven't figured out the way multiple stacks work together - unless they're writting in code the way richmond62 has offered:

Code: Select all

on openStack
   open stack "WsController"
   open stack "GuiController"
   start using "WsController"   
   start using "GuiController"   
end openStack

also - I'd love if someone could explain the diff between

Code: Select all

   open stack "WsController"

and

Code: Select all

open stack "WsController.livecodescript"

as sometimes this works for me and sometimes the other ...

you guys provide great help in a great enviroment, I am sorry if I seem hostile sometimes, I just feel puzzled more often than I expected

and bogs was right - I can now attach images - I guess there was a 10 post min before you do that ... so I am past that

[bogs]

and bogs was right -

I don't count on seeing THAT too often hahaha

you guys provide great help in a great enviroment, I am sorry if I seem hostile sometimes, I just feel puzzled more often than I expected

No sweat, welcome to the club

As far as multiple stacks and comparing the way projects are stored vs. say, .Net projects / solutions (I believe you brought that one up) it really just comes down to different terminology for the same thing.

For instance, look at the stacks that form the Lc IDE....

Quite a list of eh...

aPic_LcIde.png (16.8 KiB) Viewed 9269 times

...and compare it to the .net version...

We're not so different eh?

In .Net, the "solution" is the equivalent of a "stack" in Lc, and the "form" in this case, would be the "cards" in Lc (keep in mind this is a broad comparison).

Just like you can have multiple forms in .Net, you can have multiple "cards" in a single stack. If you look at the picture of the Lc stacks up there, you will see that Mainstack "Home" has a sub stack, no different than the picture of the .Net IDE having an added project to CarLogger.

In a situation where you are just calling a substack of a main stack, you probably don't have to reference the extension. If the stack is in memory already, you also don't have to reference the extension. If you call it out of the blue though, then I believe the extension is required.

Does that help at all?

[foosmaster]

@bogs, I somewhat disagree with your comparison:
Card is indeed like form, but stacks are like project, and what I am missing here is the concept of solution

you can have dependancies between stacks (just like you'd have in .net - using that example) to define the dependencies between the projects.

so again - my question - we all understand and agree there's a dependency between 1 stack to another.
where is it represented ?
do I just open them in the IDE manually?
do I set it in the code of the main stack ? if so - should I add .livecodescript to the open stack ?

[Mikey]

Sometimes the dependency or the connection is explicit via an object property and sometimes it is via code. You can do either one. You can even use a script to create an SOS and either insert it into the message path or assign it as a behavior of another object, including another SOS.

[bogs]

@bogs, I somewhat disagree with your comparison:
Card is indeed like form, but stacks are like project, and what I am missing here is the concept of solution

You'll have to forgive my having typed...

In .Net, the "solution" is the equivalent of a "stack" in Lc, and the "form" in this case, would be the "cards" in Lc (keep in mind this is a broad comparison).

...that should have been *Project*, just as I indicated in the picture.

As far as I remember (mind you, I did not spend long in .Net, it was towards the tail end of my time in Windows and I had already shifted back to Delphi by then), the 'solution' wasn't much more than an overall folder encompassing everything else for a particular project, glued together with an xml file. Lc doesn't have an equivalent, as far as I am aware, however I think Mikey pretty much listed all of the options.

When I am creating a project, I make a folder for it and save the stacks belonging to it to that folder (or in subfolders, depending on the role of the stack). If you look in the IDE's folder, you see the same kind of structure. As I create a new stack, I open it through code when the main project stack opens. There are, as Mikey pointed out, many other ways to do it as well.

Just as an off the top of my head thing, you *could* set the defaultFolder to your main stack's folder on opening, grab all the file names, and if ".livecode" is among them (or whatever you named your stacks), open it up. I find this far more flexible than the way solutions were implemented for a lot of reasons. YMMV.

[foosmaster]

@Mikey - you gave me the answer - the inclusion comes from behavior or code or anything like that, there's no central point that holds all the 'necessary files' needed to run a project
that's fine, I just needed an answer (that answer)
Thanks

[jacque]

That is NEAT! < Tucking that one away in the 'Tips learned from Jacque' file...>

To be honest, it isn't any different than choosing "Revert to saved..." from the File menu, except you don't have to deal with the confirmation dialog. That's the same reason I prefer to type "delete this stack" as opposed to choosing "Close and remove from memory..." <click, confirm,click,click>

Of course, there was the time I typed "delete this stack" out of habit and all my unsaved changes went away. And the time I did it to a substack and then accidentally saved the mainstack.You really don't want to do that.

[jacque]

also - I'd love if someone could explain the diff between

Code: Select all

   open stack "WsController"

and

Code: Select all

open stack "WsController.livecodescript"

as sometimes this works for me and sometimes the other ...

If the stack is already in memory, you can refer to it by its short name. If it isn't, you need the file reference so LC can find it. Assuming the stack is in the same directory as your mainstack, and the default folder is set properly, "WsController.livecodescript" is enough. If the file is somewhere else on the drive, you'd need a full (or at least a relative) file path.

LC provides a way to avoid having to construct full file paths for stacks on disk: the stackfiles. It's a way to provide a relative file path once, so that you can always refer to a stack by its short name and LC will know where to look for it.

[bogs]

That is NEAT! < Tucking that one away in the 'Tips learned from Jacque' file...>

To be honest, it isn't any different than choosing "Revert to saved..." from the File menu...

It is different, I knew about one, and now I know about both

Of course, there was the time I typed "delete this stack" out of habit and all my unsaved changes went away. And the time I did it to a substack and then accidentally saved the mainstack.You really don't want to do that.

Bet that was fun, eh wot?

LC provides a way to avoid having to construct full file paths for stacks on disk: the stackfiles.

Another gem I hadn't come across yet... <scribbling into the tips stack some more>....

[bogs]

In .Net, the "solution" is the equivalent of a "stack" in Lc, and the "form" in this case, would be the "cards" in Lc (keep in mind this is a broad comparison).

You know, after spending a little time in VS again yesterday, I think this statement was correct after all. The main stack *is* the equivalent of the solution in VS, it just also happens to be similar to the project as well. The Main stack always knows where the substacks are, after all, and everything else that is involved in the project.

You could add other 'solutions' in VS, you can add other MainStacks in Lc. You can add other 'projects' in VS, you can add subStacks in Lc. I fail to see the difference at this point.

[hrcap]

Hi All

Regarding Encryption:

This is something that I was struggling with as the SOSs were being included within the standalone bundle as text files that could be edited by the end user.

After much experimentation this can be solved by loading all of the SOSs as substacks of the main stack before creating the standalone. The SOSs are then included within the main 'binary' build and are not editable by the end user.



Regarding Globals:
I believe globals can be used but I find it tidier to pass the variables to the SOS for example:

this_is_the_sos t_var1, t_var2, t_var3


once the SOS has carried out its activities any results can then be passed back to the calling script using e.g.

return var_result



Many Thanks

[bogs]

After much experimentation this can be solved by loading all of the SOSs as substacks of the main stack before creating the standalone. The SOSs are then included within the main 'binary' build and are not editable by the end user.

Want to expand on that one a bit? Exact steps, etc ?

[kaveh1000]

I am also very interested in your solution. I use several SoS's and I want them automatically encrypted when I build a standalone. Pls see this thread:

https://forums.livecode.com/viewtopic.p ... 22#p188122

[mrcoollion]

Not really sure but is this a way to do it (Windows 10)?
Build this in a button with mouseUp for testing.
First, know the path of the SOS. In this case it is placed in the same folder as the application stack. For this I used a function MainStackFolder Coded by jmburnod (Jean-Marc). [see remark from Klaus, use : specialfolderpath("resources")].
I make the SOS available with 'start using stack tPathAndStackName'.
Then I set the mainstack of the script only stack (tPathAndStackName) to the short name of my main application stack (tMainStackName).
Now I guess the SOSs are included within the main 'binary' build and are not editable by the end user?

Code: Select all

on mouseUp
   put the short name of this stack into tMainStackName
   put MainStackFolder() into tPath
   put tPath&"/SOS2Integrate.livecodescript" into tPathAndSOStackName
   start using stack tPathAndSOStackName
   set the mainstack of stack tPathAndSOStackName to tMainStackName
end mouseUp

function MainStackFolder
   put the filename of this stack into rMainStackFolder 
   put the platform  into tPlatForm
   put the environment into pEnv
   put the itemdel into OID
   set the itemdel to "/"
   put the num of items of rMainStackFolder into nbF
   if tPlatForm = "MacOS" then 
      if pEnv = "standalone application" then
         delete item (nbF-3) to nbf of rMainStackFolder
      end if
      if pEnv = "development" then
         delete last item of rMainStackFolder
      end if
   else
      delete last item of rMainStackFolder
   end if
   set the itemdel to OID
   return  rMainStackFolder
end MainStackFolder

Regards,

Paul

[Klaus]

Dag Paul,

In this case it is placed in the same folder as the application stack.

in this case you can also use -> specialfolderpath("resources")
This specialfolderpath also works in the IDE and delivers exactly that folderpathname.


Best

Klaus