Stacks and stack files

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

Post Reply
noloop
Posts: 13
Joined: Thu Oct 07, 2010 2:26 am

Stacks and stack files

Post by noloop » Fri Oct 15, 2010 12:02 am

I'm at a loss trying to understand the file structure. When I rename a stack by choosing "Save as..." it creates a new file as far as the OS goes, but when I open it, the name of the stack is the original name. If I want to save as an application, it insists on including the original stack as a stack file. I don't get it. When I choose "Save as..." I want to create a new file, a new stack. Is there some kind of dependency system, where the new file only contains changes from the original?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10045
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Stacks and stack files

Post by FourthWorld » Fri Oct 15, 2010 1:23 am

A stack file can have any number of stacks within it, one mainstack and zero or more substacks. The name property of a stack object is independent of the name of the file it's contained in.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

noloop
Posts: 13
Joined: Thu Oct 07, 2010 2:26 am

Re: Stacks and stack files

Post by noloop » Fri Oct 15, 2010 3:59 am

It seems to assign the name of the file to the name of the stack, when you choose "Save as..." It's really confusing. I don't want Fun App 2.0 to contain a stack called Fun App 1.0, which is what I have now. This is really confusing when I also have a file named Fun App 1.0 in the same folder. Is that really how it's supposed to work?

Bantymom
Posts: 73
Joined: Fri Aug 27, 2010 4:32 am

Re: Stacks and stack files

Post by Bantymom » Fri Oct 15, 2010 6:55 am

I was very confused by the same thing for awhile. I would SaveAs a stack, but when I would open the previous version again to check something, it would tell me I already had a stack of that name open and ask me what I wanted to do with it. I finally figured out what it was talking about and that the new file name wouldn't change the stack's Name. So, new routine:

1) Save my stack with the new changes using Save As to give it a new file name.
2) Immediately go to the Basic Properties of the stack to change the Name and Title (which I think is the name that actually appears at the top of the window?) of the stack I just "Saved As" before closing it, to make it an entity separate from the stack of the previous name.

If I don't do this, it just makes me confused and crazy (though that isn't particularly difficult in my case)

None of the Stacks I have saved have become part of another one, but then again, I can't make stand-alone applications, so I am probably missing that part of your difficulty.

Cheers,
Bantymom
2nd-grade Teacher, Poultry Fancier, Scottish Country Dancer
and Perpetual Beginner

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10045
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Stacks and stack files

Post by FourthWorld » Fri Oct 15, 2010 4:35 pm

noloop wrote:It seems to assign the name of the file to the name of the stack, when you choose "Save as..." It's really confusing. I don't want Fun App 2.0 to contain a stack called Fun App 1.0, which is what I have now. This is really confusing when I also have a file named Fun App 1.0 in the same folder. Is that really how it's supposed to work?
When you first save a stack, and when you choose "Save As...", it gives you the opportunity to name the file whatever you like.

The file name, the stack object's name property, and the stack object's label property (what the user sees in the title bar) are all independent of one another, and all of them are fully under your control to use however you like. When the stack's label property hasn't been set it will display the stack's name, but there it's often useful to set the name and the label to different values.

For example, the mainstack that I use to make my standalones from is often named something very short since I'll be using it a lot in scripts when addressing the object. For example, in my WebMerge product the mainstack is named "fwwm"; meaningless to anyone else, but a usefully short name for me to type, and having one name for every version means my scripts always work as I keep enhancing the program from version to version.

Of course I don't want to the user to have to see "fwwm", so I set the stack's label to the full name of the application along with the version.

In the stack's preOpenStack handler you could use:

Code: Select all

on preOpenStack
   set the label of me to "My Cool App 1.0"
end preOpenStack
Or even simpler, just set the label in the Inspector and you're done.

That's not a bad approach for simple apps, but as you make more and more apps, or as your app grows, you may find it cumbersome to hard-wire the app's name and version number in code; every time you change the version you'll need to hunt down every bit of code that uses it and change it. At a minimum the app name and version number will appear in the About box as well, so you'll have at least two places to change it. If you also use those strings in your Help stacks there will be just that many more places to make changes, increasing the amount of work you need to do to roll out each new version.

I'm far too lazy for that, so I often use accessor functions for common info like the app name and version, obtaining that info from custom properties:

Code: Select all

on preOpenStack
  set the label of me to AppName() && AppVersion()
end preOpenStack
In my stack script I have functions for AppName and AppVersion, which they get from custom props, e.g.:

Code: Select all

on AppName
   return the uRIP["AppName"] of this stack
end AppName
I happen to use a custom property set named uRIP for reasons we can get into latter; you could use any valid property name you like if this method appeal to you. One nice thing about such an approach is that it lets you reuse code easily from app to app, changing only property values to have the appropriate strings displayed.

For documents, while I often use stack files for data storage because of the convenient efficiency of custom properties for storing stuff, I usually use it for storage only, with any views showing that data implemented as substacks of my app mainstack. This lets me update the user interface at any time without affecting the user's data files.

That's a whole other story we can get into later.

For now, if you want your stack to display the same name as the file you could set its name property, but doing so may be less robust than you'd like because every time you change the file name you'd need to change any scripts that refer to that stack object.

Instead, you might consider simply using one name for all versions of your stack, and just changing the label of your stack, similar to how I've shown above. If you want that label to reflect the file name, you can get the fileName property of the stack and parse out the last element from it:

Code: Select all

on preOpenStack
   put the filename of this stack into tFileName
   if tFileName is empty then -- never been saved before
      put "My Default Name" into tFileShortName
   else
      set the itemdel to "/"
      put last item of tFileName into tFileShortName
      -- Now you have the short name of the file; if you want to remove the
      -- file suffix you could use:
      set the itemdel to "."
      delete last item of tFileShortName
   end if 
   -- Now we can set the label of the stack to the string we've parsed:
   set the label of this stack to tFileShortName
end preOpenStack
While all this flexibility may seem confusing at first, as you build more stuff with LiveCode you'll come to appreciate having total control over each of these elements independently of one another. The filename, the stack name, and the stack label each play a different role, and you're in the driver's seat in terms of how you use them in your project.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Post Reply