load script only stack and call one of its functions

[PureMoxie]

Hi,

As I start doing more things with LC, I have noticed I am using a lot of the same database code across projects. So, I want to move a lot of that into a script-only stack that I can use as a library.

I am trying to set a custom property on a normal stack that will store the database name used for the project (all local sqlite dbs at this point). I then want to include my db library script stack and pass that property to a function in the script only stack to connect to the database.

First step is something like this in my project's (normal stack) card script:

Code: Select all

on preOpenStack
   start using stack dbLib
   insert the script of stack dbLib into front --even necessary?
   put the dBname of stack "thisStack" into tDbName
   setDbName(tDbName)
end preOpenStack

The setDbName function is in my dbLib script stack. However, I get "can't find handler" when calling that function.

Both the project stack file and the dbLib livecodescript file are in the same directory.

[PaulDaMacMan]

Code: Select all

on preOpenStack
   start using stack dbLib
   insert the script of stack dbLib into front --even necessary?
   put the dBname of stack "thisStack" into tDbName
   setDbName(tDbName)
end preOpenStack

The setDbName function is in my dbLib script stack. However, I get "can't find handler" when calling that function.

Both the project stack file and the dbLib livecodescript file are in the same directory.

start using stack dbLib
my guess is that here dbLib is an empty variable as far as preOpenStack is concerned (unless you declared it as a global variable somewhere else, not likely since it's in a preOpenStack handler).
dbLib variable needs to contain file path information to the dbLib.livecodescript file.

[PureMoxie]

Thanks, Paul - I tried updating to the code below (spaces around dots in file name are for getting past the forum software) but am still getting "can't find handler:"

Code: Select all

on preOpenStack
   start using stack "C:\Users\chris\Documents\My LiveCode\dbLib . livecodescript"
   put stacksinuse
   insert the script of stack "C:\Users\chris\Documents\My LiveCode\dbLib . livecodescript" into front
   put the dBname of stack "thisStack" into tDbName
   setDbName(tDbName)
end preOpenStack

Interestingly, adding "put stacksinuse" returns 'dbLib' in both my first and this example.

Generally speaking, is preOpenStack the best place to load script only library stacks?

[PaulDaMacMan]

Side note:
put the dBname of stack "thisStack" into tDbName
setDbName(tDbName)
I think here you could do:

Code: Select all

put the dBname of me into tDbName 

The "me" keyword is a reference to the current object that a script is running in, in this case should return the same as using the 'this stack' keywords.
The string literal ""thisStack" probably is not the actual name of your target stack, did you mean to use the 'this stack' keywords?

Maybe 'setDbName(tDbName)' has an error in it's code that is preventing it from being parsed properly ? That would make it so that the engine couldn't find it.

If setDbName doesn't return information to the caller then maybe it should be a command instead of a function.
You would call a command version like this:

Code: Select all

setDbName tDbName -- note the no parentheses around the parameter

[PureMoxie]

Ah, I got it - a function must return something. I hadn't gotten that far and was just putting something out to the message window in my function. I also see that a handler makes more sense anyway if no return value is needed.

Also, I think I read somewhere to always put preOpenStack in a card script, so I thought any "me" in the card script would refer to the card?

[PaulDaMacMan]

Also, I think I read somewhere to always put preOpenStack in a card script, so I thought any "me" in the card script would refer to the card?

My bad, your'e correct. preOpenStack gets sent to the card not to stack, so 'me' would be a reference to the card in that case.

Glad you get it worked out.

[SparkOut]

Code: Select all

on preOpenStack
   start using stack dbLib
   insert the script of stack dbLib into front --even necessary?
   put the dBname of stack "thisStack" into tDbName
   setDbName(tDbName)
end preOpenStack

To answer the other question you made in the commented code, you very probably don't need to insert the script into front. If you "start using" a stack it makes its functions accessible and handlers available in the message path.
You only need to insert a script into front if you want to manipulate the message path and ensure that your script handlers are triggered before reaching any other native or custom handlers - for instance you might want to override the normal behaviour of another handler and have your front script intercept it and run, then pass the message (or not) according to your design.
I don't think you would ever need both to "start using" AND "insert into" for the same script.

[jacque]

Also I'm not sure a frontscript would intercept a command from the message box. At any rate, I agree using it as a frontscript isn't necessary.

Functions don't really need to return a value, though they usually do. The syntax is important though, if it isn't correct you'll get "can't find handler" which implies the parentheses around the parameters are missing in the calling handler.

[PaulDaMacMan]

Functions don't really need to return a value, though they usually do.

I'm getting used to LiveCode Builder where it seems functions do need to return even if that is just a line with the word return or return nothing (ie. void). I guess it's more of a, in my opinion, best practice in LiveCode Script.

[FourthWorld]

FWIW any stack can be used as a library. It doesn't need to be a script-only stack.

A regular stack file has other advantages which may be useful, like the ability to have custom properties persistent between sessions, or even controls, substacks, or other objects if you find yourself wanting to store commonly-used UI elements there.

Of course if you work for an organization dependent on version control systems designed for other languages, you'll have no choice.

In my experience people seem to have an easier time getting started when they use regular stacks unless they have a specific reason not to.

[PaulDaMacMan]

A regular stack file has other advantages which may be useful, like the ability to have custom properties persistent between sessions, or even controls, substacks, or other objects if you find yourself wanting to store commonly-used UI elements there.

Well there is ways to do that with script-only, as long as you have write access to the library .livecodescript file. You can have a library with routines that appends more arbitrary data to the library file itself. I've embedded binary or GUI things in script-only stack files using Base64 encoding, with scripts that build the library from a passed directory parameter.

In my experience people seem to have an easier time getting started when they use regular stacks unless they have a specific reason not to.

I suppose script-only can be a bit more tricky than a regular stack. It's a relatively new stack format as well (I forget which version, LC7 the refactoring?). The binary stack format is best for beginners I guess.
But script-only has advantages too, it may be a more familiar workflow style for someone coming from a different development environment, and like you said version control. Being able to view, edit and revert to previous versions of your code anywhere (like on your mobile) via GitHub has come in handy on occasion.