Using substacks versus external stacks

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Using substacks versus external stacks

Post by kaveh1000 » Fri Aug 16, 2019 1:18 pm

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?
Kaveh

jmburnod
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2400
Joined: Sat Dec 22, 2007 5:35 pm
Location: Genève
Contact:

Re: Using substacks versus external stacks

Post by jmburnod » Fri Aug 16, 2019 1:40 pm

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. :D
Best regards
Jean-Marc

Klaus
Posts: 11313
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: Using substacks versus external stacks

Post by Klaus » Fri Aug 16, 2019 2:09 pm

Hi kaveh,

what Jean-Mard said.
kaveh1000 wrote:
Fri Aug 16, 2019 1:18 pm
...just ensure they are bundled with the main stack to be distributed.
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 :-)
...
Best

Klaus

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Re: Using substacks versus external stacks

Post by kaveh1000 » Fri Aug 23, 2019 4:19 pm

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,
  • 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
If the above is correct, then Klaus, why do we need to specify a path with specialfolderpath, etc?
Kaveh

jmburnod
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2400
Joined: Sat Dec 22, 2007 5:35 pm
Location: Genève
Contact:

Re: Using substacks versus external stacks

Post by jmburnod » Fri Aug 23, 2019 6:13 pm

Hi kaveh,
Yes and Yes :D
You need specialfolderpath() to build filename of your external stack
the behaviour is as above
No.
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

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Re: Using substacks versus external stacks

Post by kaveh1000 » Fri Aug 30, 2019 10:26 pm

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:
  • Text manipulation
  • Getting data from servers or databases
  • Calculations
  • etc
Then I can use these "library" stacks with other main stacks. My questions are:
  • 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?
Thanks.
Kaveh

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6261
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Using substacks versus external stacks

Post by dunbarx » Sat Aug 31, 2019 3:57 am

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

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Re: Using substacks versus external stacks

Post by kaveh1000 » Sat Aug 31, 2019 8:45 am

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.

Code: Select all

on make_each_cap_letter_lower_case...
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.

Code: Select all

on TEXT_make_each_cap....
I am learning good practice late but better than never!
Kaveh

bogs
Posts: 3996
Joined: Sat Feb 25, 2017 10:45 pm

Re: Using substacks versus external stacks

Post by bogs » Sat Aug 31, 2019 12:31 pm

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
kaveh1000 wrote:
Sat Aug 31, 2019 8:45 am
prefixes for handlers...
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
Here is an example (admittedly simple) of what I'm describing -
namingTest.livecode.zip
Demo stack...
(1.01 KiB) Downloaded 14 times
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.
Image

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Re: Using substacks versus external stacks

Post by kaveh1000 » Sat Aug 31, 2019 2:48 pm

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.

Code: Select all

function getTheNumber pOne \
                      pTwo, \
                      pThree
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
Kaveh

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5155
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Using substacks versus external stacks

Post by jacque » Sat Aug 31, 2019 5:55 pm

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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

kaveh1000
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 337
Joined: Sun Dec 18, 2011 7:23 pm
Location: London
Contact:

Re: Using substacks versus external stacks

Post by kaveh1000 » Sat Aug 31, 2019 7:39 pm

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?
Kaveh

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5155
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Using substacks versus external stacks

Post by jacque » Sat Aug 31, 2019 8:21 pm

Could you elaborate on the behaviors? Are you saying you put any behaviors for a main stack in a library stack?
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.

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

bogs
Posts: 3996
Joined: Sat Feb 25, 2017 10:45 pm

Re: Using substacks versus external stacks

Post by bogs » Sat Aug 31, 2019 10:18 pm

jacque wrote:
Sat Aug 31, 2019 5:55 pm
The IDE uses stack-only scripts almost exclusively and I know of several others that do the same.
I wonder if that is causing some of the general slow down in the IDE somehow. I mean, that type of thing is relatively recent, right? Say, post 7.x?
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7024
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Using substacks versus external stacks

Post by FourthWorld » Sat Aug 31, 2019 11:36 pm

bogs wrote:
Sat Aug 31, 2019 10:18 pm
jacque wrote:
Sat Aug 31, 2019 5:55 pm
The IDE uses stack-only scripts almost exclusively and I know of several others that do the same.
I wonder if that is causing some of the general slow down in the IDE somehow. I mean, that type of thing is relatively recent, right? Say, post 7.x?
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
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Post Reply

Return to “Talking LiveCode”