Code organization

[JackieBlue]

Hi. Where do you put common functions that you may want to use across cards? I am thinking something like modules but I didn't see any equivalent in live code everything references a card or object on a card. Thanks.

[Simon]

Hi JackieBlue,
In the stack script
Take a look at the pretty picture here;
http://lessons.runrev.com/m/4603/l/4403 ... ssage-path
Ctrl+Shift+S or Cmd+Shift+S will get you there.

Simon

[JackieBlue]

I reviewed that. I'll take a look at the example stack but the documentation doesn't seem to address what I am talking about. I'd like to have a module with a bunch of functions that I can reuse across projects. For example, I have a VB code file that I wrote that I use on almost all my vb projects that handles all of the database functions - connection, execute commands, pull data and return, etc. This is coded for 2 different type of databases - MySQL and MS-SQL. I'd like to be able to replicate a similar functionality for LiveCode.

[dunbarx]

Hi.

The hierarchy of LC is a fundamental concept. Learning how to add and to manipulate arrays are all well and good, but you simply MUST know how the LC structure is organized.

So when Simon suggested the stack script, it is because you asked for a location that would cover "across cards" This is correct. When you then asked "across projects", the new best idea would be a stack placed in use, a backscript, or perhaps even a plug-in. These all sit "above" all the stacks open, or that will open in the future, in the current session.

Hierarchy. It means just what it says. It is a paradigm through which all messages pass, and are ordered. There is a diagram in the user guide I think.

Craig Newman

[JackieBlue]

Thank you. I understand the hierarchy concept, this is basically the same thing as scope. .Net (and C) have the same thing. Your function/object can exist at different levels and the compiler (or interpreter) will go up the hierarchy until it finds what you are looking for. This is very clear in .NET and I can put my code in a module that will then be referenced from any form (i.e. card) as long as it is declared as public. Obviously LiveCode does not have the public/private functionality (variables/objects/procedures are not typed). I suppose the stack script covers some of this. However, being able to import stack script to projects should be possible. On small projects it is not a problem but as projects gets larger it will be a pain to manage it, especially across more than 1 developer. I hope that I am missing something on this because I believe this is a bigger deal than HTML5 (which I supported) is.

[mwieder]

Jackie- the concept you're looking for here is libraries. Or possibly frontscripts and backscripts, which are selectively placed library stacks. Within a stack ecosystem you can also leverage behaviors.

But I'd start by checking the dictionary for "start using" and "stop using" commands.

[jacque]

There are also private commands and functions. See the term "private" in the dictionary.

[mwieder]

Jacque- yes, but the op specifically requested "I'd like to have a module with a bunch of functions that I can reuse across projects."

[JackieBlue]

Thank you all again. So I think I understand how this is accomplished in LiveCode. For example, if I wanted to create a code library, I would create a separate stack. Within this stack I would have scripts (and not necessarily an interface) that I could reference in whatever project I was coding by using the Start Using xyz command and Stop Using when I was done. I'm not sure why you would need a "Stop Using" since I assume you would want access to this library the whole time, except maybe as clean up when you are exiting the program but even then it shouldn't be needed since when the environment is ended you are done. Seems like this should be just like an #include file in C.

From a distribution perspective, stand alone, how does this work? Do I create 2 stand alone apps or does LiveCode create the one file? My assumption to this point that this is an interpreted language that creates an encrypted stand alone app that includes a runtime version of LiveCode, correct?

[jacque]

I usually make the library stack a substack of my mainstack, so it won't get separated and is always available. Then soon after startup, in preOpenStack or somewhere close, I start using the stack. In a standalone I don't usually stop using it unless it would interfere with other libraries since as you say, it isn't really necessary because in a standalone everything gets wiped out during a quit. During development though, I usually stop using the library when I'm not working with the mainstack to avoid potential conflicts.

[rayjbenet]

From a distribution perspective, stand alone, how does this work?

Keep this library stack in a folder somewhere easy to find consistently in your development area - probably call it "Libraries" or "My Libraries". Under the File menu, within "Standalone Application Settings...", click the "Stacks" link, then "Add Stack File..." and add your library.

The effect of this is that the "stackfiles" property of your stack (check it in the dictionary for details) gets modified to include your library in the list.

This means you don't have to open the library stack in development (it gets done for you), and when you build your standalone, it will be included.

The caution is twofold: make sure you keep your Master Library and any "project copies" of your library sync'd up (source code control in LiveCode is a an exercise in good backup strategies, not elegant source code control); know that the stackfiles property you just added for this library uses a relative reference to the same root folder as your project.

This works the best for me.