Using substacks versus external stacks
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Using substacks versus external stacks
I have around 10 substacks in a mainstack. I have been wondering what the relative advantages are to having external stacks instead and when building a standalone, just ensure they are bundled with the main stack to be distributed.
Any general advice?
Any general advice?
Kaveh
-
- VIP Livecode Opensource Backer
- Posts: 2718
- Joined: Sat Dec 22, 2007 5:35 pm
- Location: Genève
- Contact:
Re: Using substacks versus external stacks
Hi Kaveh,
I use extrenal stacks because it can be updated without compil
As Klaus said we can't save an external stack from a standalone but we can export/import data from .txt files, i mean content but properties of controls too.
Best regards
Jean-Marc
I use extrenal stacks because it can be updated without compil
As Klaus said we can't save an external stack from a standalone but we can export/import data from .txt files, i mean content but properties of controls too.
Best regards
Jean-Marc
https://alternatic.ch
Re: Using substacks versus external stacks
Hi kaveh,
what Jean-Mard said.
Best
Klaus
what Jean-Mard said.
In that case add all of your separate stacks via the "Copy files" tab in the "Standalone Application Settings" and access them in your standalone with:
Code: Select all
...
put specialfolderpath("resources") & "/name of separate stack.livecode" into tExternalStack
## Now do whatever you like with tExternalStack :-)
...
Klaus
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Re: Using substacks versus external stacks
Thank you Jean-Marc and Klaus
Sorry to come back late on this, but is my understanding correct that when using the Standalone Application Settings window,
Sorry to come back late on this, but is my understanding correct that when using the Standalone Application Settings window,
- If I have external stacks that are needed for the main stack to run, I add these using the stacks panel. The stack is then saved in the standalone and travels with it when I distribute the Standalone
- If I have external files, e.g. text files that I want to bundle with the Standalone, then I use the Copy files panel, and the behaviour is as above
Kaveh
-
- VIP Livecode Opensource Backer
- Posts: 2718
- Joined: Sat Dec 22, 2007 5:35 pm
- Location: Genève
- Contact:
Re: Using substacks versus external stacks
Hi kaveh,
Yes and Yes
You need specialfolderpath() to build filename of your external stack
You can open a stack from the mainstack but you only can import the content of a file ".txt". or launch it by an other software.
Best
Jean-Marc
Yes and Yes
You need specialfolderpath() to build filename of your external stack
No.the behaviour is as above
You can open a stack from the mainstack but you only can import the content of a file ".txt". or launch it by an other software.
Best
Jean-Marc
https://alternatic.ch
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Re: Using substacks versus external stacks
Hi again
Continuing the idea of using several stacks...
I have a stack that is getting bigger as I write code (mostly in the stack script). So I am thinking that I can divide scripts by different functionalities and have have a library stack for each. For instance one stack for each of the following sets of scripts:
Continuing the idea of using several stacks...
I have a stack that is getting bigger as I write code (mostly in the stack script). So I am thinking that I can divide scripts by different functionalities and have have a library stack for each. For instance one stack for each of the following sets of scripts:
- Text manipulation
- Getting data from servers or databases
- Calculations
- etc
- In general is this a good idea – perhaps obvious?
- What are good working practices? For instance is there a recommended naming convention for handlers so I do not have the same handler name in a main stack and a library stack?
- Any other ideas for good practice?
Kaveh
-
- VIP Livecode Opensource Backer
- Posts: 9670
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Using substacks versus external stacks
Is it simply because the length of the stack script is getting large that you want to split it up? I sort of get that; scrolling down way down to find, say, a function handler called from way up is oftentimes a bit of work, and a myriad of handlers can be hard on the eyes.
But that is what the sidebar of handler names is for, to be able to simply "go" to any of them. In other words, I would find it much more onerous to have to open another script window in another stack to check on the workings of a distant handler than to either scroll or "go" to one.
A library of such goodies is fine if you rarely need to examine, upgrade or fix them. I have a bunch of these, tried and true gadgets that I never examine anymore, just call them as needed.
I guess it is a matter of style, but in a stack under construction I keep everything close by.
Craig
But that is what the sidebar of handler names is for, to be able to simply "go" to any of them. In other words, I would find it much more onerous to have to open another script window in another stack to check on the workings of a distant handler than to either scroll or "go" to one.
A library of such goodies is fine if you rarely need to examine, upgrade or fix them. I have a bunch of these, tried and true gadgets that I never examine anymore, just call them as needed.
I guess it is a matter of style, but in a stack under construction I keep everything close by.
Craig
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Re: Using substacks versus external stacks
Good point Craig...
The long script secondary, but it is still nice not to have a lot of text in the same script. one reason is that LC slows down significantly with long scripts. I now have 4000 lines (I use a lot of split lines with "\" for readability too) and I invariably have to wait for the editor to catch up especially when I enter a new line. That is not nice. (Using 9.0.5 on Mac).
But the main incentive is to have specific stacks that a colleague can maintain and add to independently of a main stack, and just more order.
Regarding the naming of handlers, any hints there? I have taken on André Garcia's recommendation of naming handlers clearly even if long, so e.g.
but still the number of handlers are huge and hard to pin down. Any other hints, whether I use one stack or not, e.g. do you use prefixes for handlers, e.g.
I am learning good practice late but better than never!
The long script secondary, but it is still nice not to have a lot of text in the same script. one reason is that LC slows down significantly with long scripts. I now have 4000 lines (I use a lot of split lines with "\" for readability too) and I invariably have to wait for the editor to catch up especially when I enter a new line. That is not nice. (Using 9.0.5 on Mac).
But the main incentive is to have specific stacks that a colleague can maintain and add to independently of a main stack, and just more order.
Regarding the naming of handlers, any hints there? I have taken on André Garcia's recommendation of naming handlers clearly even if long, so e.g.
Code: Select all
on make_each_cap_letter_lower_case...
Code: Select all
on TEXT_make_each_cap....
Kaveh
Re: Using substacks versus external stacks
I'll start off by saying that, for the vast majority of the programs and utilities I write, I haven't yet exceeded 1k lines, and so haven't found the necessity for using library stacks outside of testing them while I was initially learning Lc.
My hats off to you for writing something that actually needs 4k lines in any format!
Having said that, my belief is that libraries are best suited for exactly what Craig says, functions / handlers that you -
* use often
* have worked all possible bugs out of
* have (hopefully) documented so less often used ones don't trip you up when you come back to them years later
For naming variables, I go mostly with the old standard camel case method of 3 or 4 chars, then name (however long), for my own stuff. I find this is easiest to read, but again, I learned it a long time ago and spent many years using it. An example of my typical naming for variables would be (like I showed in the editor video) :
-- temporary - tmpVar
-- local - lclVar
-- global - gblVar
-- custom property - cpropProperty
...etc.
I use the same style of naming for handlers/functions/ object naming, mostly without dashes or underscores since the capital letter making the break obvious. For example :
-- field for text to be entered/changed - field "txtMyField"
-- field that is a label, button, or otherwise unchanged - field "lblField"
-- typical button - button "cmdOneShot"
{ or button "cmd156Shot" when using much longer numbers as part of the name}
...etc.
Doing this makes it easy to target specific controls with one line of code, AND has the added bonus of making it almost impossible to use a built in command, function, or object name. For example:
Here is an example (admittedly simple) of what I'm describing -
However, if you are looking to write variables today, as well as a pretty nicely formatted guide on scripting in general, I'd point you instead to Richard's excellent text on the subject -
http://www.fourthworld.com/embassy/arti ... style.html
In it, he covers a lot of topics. Here is the TOC -
Contents:
Introduction
General Scripting Techniques
Top-Down Handlers
Clarify Program Flow
Comment Effectively
Comments as Breadcrumbs: What? Bang! Hmmm
Code for Reuse
Code for Speed
Naming Conventions
Variables and Arguments
Handlers and Functions
Objects
As you can see, it covers quite a bit of ground, and comes from the knowledge of quite a few that have been around in this language enough to know it expertly, making it well worth the time to read.
My hats off to you for writing something that actually needs 4k lines in any format!
Having said that, my belief is that libraries are best suited for exactly what Craig says, functions / handlers that you -
* use often
* have worked all possible bugs out of
* have (hopefully) documented so less often used ones don't trip you up when you come back to them years later
I'm hardly the poster boy for writing good code, but I only prefix variables. I agree with Andre's recommendation for naming them, if done correctly you shouldn't need to prefix it, the name will tell you what you need to know.
For naming variables, I go mostly with the old standard camel case method of 3 or 4 chars, then name (however long), for my own stuff. I find this is easiest to read, but again, I learned it a long time ago and spent many years using it. An example of my typical naming for variables would be (like I showed in the editor video) :
-- temporary - tmpVar
-- local - lclVar
-- global - gblVar
-- custom property - cpropProperty
...etc.
I use the same style of naming for handlers/functions/ object naming, mostly without dashes or underscores since the capital letter making the break obvious. For example :
-- field for text to be entered/changed - field "txtMyField"
-- field that is a label, button, or otherwise unchanged - field "lblField"
-- typical button - button "cmdOneShot"
{ or button "cmd156Shot" when using much longer numbers as part of the name}
...etc.
Doing this makes it easy to target specific controls with one line of code, AND has the added bonus of making it almost impossible to use a built in command, function, or object name. For example:
Code: Select all
on mouseEnter
if char 1 to 3 of the name of the target is "lbl" then set the backColor of the target to "green"
end mouseEnter
http://www.fourthworld.com/embassy/arti ... style.html
In it, he covers a lot of topics. Here is the TOC -
Contents:
Introduction
General Scripting Techniques
Top-Down Handlers
Clarify Program Flow
Comment Effectively
Comments as Breadcrumbs: What? Bang! Hmmm
Code for Reuse
Code for Speed
Naming Conventions
Variables and Arguments
Handlers and Functions
Objects
As you can see, it covers quite a bit of ground, and comes from the knowledge of quite a few that have been around in this language enough to know it expertly, making it well worth the time to read.
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Re: Using substacks versus external stacks
Thank you for taking the time to write Bogs and for the stack that shows what you are describing. All useful and also thanks for reminder to go back to Richard's blog that I am already following mostly but I had forgotten some details of.
Regarding lines of code, bigger certainly does not equate to better! A lot of cleaning up has be done as I have written bloated code, and there is a lot of redundant code too. But my practice of putting parameters on separate lines for readability, e.g.
certainly does not help the number of lines. I use the line break character "\" liberally.
Back to coding now hopefully with more good practice!
Regards
Kaveh
Regarding lines of code, bigger certainly does not equate to better! A lot of cleaning up has be done as I have written bloated code, and there is a lot of redundant code too. But my practice of putting parameters on separate lines for readability, e.g.
Code: Select all
function getTheNumber pOne \
pTwo, \
pThree
Back to coding now hopefully with more good practice!
Regards
Kaveh
Kaveh
-
- VIP Livecode Opensource Backer
- Posts: 7238
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Using substacks versus external stacks
Libraries are useful for anything that can be reused elsewhere and I think many of us have a few. I also split out code that can be used as behaviors. This keeps the main app's working code separate from the reusable stuff and allows you to focus primarily on the new scripts during development.
The IDE uses stack-only scripts almost exclusively and I know of several others that do the same. That's a bit hard for me to follow, so I use a mixture that makes sense to me.
The IDE uses stack-only scripts almost exclusively and I know of several others that do the same. That's a bit hard for me to follow, so I use a mixture that makes sense to me.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- Livecode Opensource Backer
- Posts: 508
- Joined: Sun Dec 18, 2011 7:23 pm
- Location: London
- Contact:
Re: Using substacks versus external stacks
Thank you Jacqueline. Interesting about IDE...
Could you elaborate on the behaviors? Are you saying you put any behaviors for a main stack in a library stack?
Could you elaborate on the behaviors? Are you saying you put any behaviors for a main stack in a library stack?
Kaveh
-
- VIP Livecode Opensource Backer
- Posts: 7238
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Using substacks versus external stacks
Usually in a script-only stack, since they don't need to get the "libraryStack" message. And sometimes I just put them into a button in the mainstack so they travel with the app automatically without needing to set the stackfiles property.Could you elaborate on the behaviors? Are you saying you put any behaviors for a main stack in a library stack?
Library stacks are LC binary files rather than text files, and when put in use they get a "libraryStack" message which you can use to do any setup that may be necessary.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Using substacks versus external stacks
Probably not, at least not anything beyond boot time.
Script-only stacks are just stacks, the same as any other, differing only in storage format.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn