LiveCode Forums.

I have a question regarding LiveCode’s code library paradigm. I came from Java and Python, so I’m used to organizing my code into libraries to make future projects easier. However, I’m not 100% sure how to achieve this in LiveCode yet. To be honest, working with LiveCode feels like I’m working backwards. That’s not a criticism, though. It just feels weird designing and then coding.

Everything is so visually oriented; I have the opposite reaction I normally possess while coding and then trying to map that into a visual program. With LiveCode it’s just the opposite. I start with a visual representation and then map out the code. While this makes UI design much more efficient, it leaves me wondering how to best organize my code into manageable libraries. Fortunately, though, the manual mentions this as a suggestion on page 159 (UserGuide, 2011).

Unfortunately, it doesn’t go into a lot of detail. It specifies that a code library is created by placing the desired handlers into any object available to your stack. But then it seems to get somewhat ambiguous. Such as the purpose behind the insert script and the start using commands. It says, “Typically you would run one of these commands as your application is starting up, so that all the scripts can access the libraries you require” (UserGuide, 2011).

It then goes on to describe front scripts and back scripts -- of which I understand. What I want to know is what are some general guidelines for creating a well organized library like this?

I’m not sure, but here’s what I think the manual is saying. Say, for example, I am creating a library for interacting with SQLite. I would create a new stack and name it something like SQLLib. Then in the main stack, I could map out my custom commands and functions. Then if I ever want to use anything it defines, it’s simply a matter of referencing the SQLLib stack whenever appropriate. But if that is the case, and a stack serves entirely as a library, what good purpose do sub-stacks serve for such a stack? I suppose it could serve to further break libraries down into sections. But, again, I’m not sure. Your advice is greatly appreciated.

Thanks for your time
Sincerely,
Sanoski

Sanoski-

Yes, I know just what you mean going back and forth between different development environments. Creating a linked list, for example, is quite easy in c or java or... but ridiculously difficult in LiveCode because you're dealing with code classes rather than visual screen objects. LiveCode does make you think much more about your visual display as your primary object orientation rather than as an adjunct to your code logic.

Libraries: there's nothing particularly hard (or shouldn't be, anyway) about libraries. Put your code in the stack script and you can simply say
and it's then available for all stacks to use.

Or you can put the code in an control object (a button, for example) and
or into back

I use both "start using" and "insert into" depending on the situation, but usually use the insert command only if I need a frontscript to grab system messages before anyone else has a chance.

As you surmised, substacks of a library stack aren't much use. The only advantage you might have is in separating your library code into different sub-areas. In the SQLite example, you might have a substack whose code is related to queries, one for form data, etc; but you'd have to be very explicit about references to the substacks in your main library stack code, and those drawbacks would probably offset any gains from separating the functionality. And you need to be very aware that you can't have substacks of substacks.

Thanks a lot for your help. I figured it's one of those give and take situations. LiveCode makes it much easier to be outrageously productive even when you're just starting off, but along with that simplicity comes sacrifices. Thanks again for your assistance.

Yeah, I long for the day when we can have real objects in our code with subclassing and reusability and all that stuff. But I'm four or five times more productive in LiveCode than in my other development environments, so I can't really complain all that much.