LiveCode Forums.

Read before jumping to conclusions, please --- a 'reply' to an old post ...

I read "HyperCard is Dead" - ok, I'm cool with that.
"LiveCode" is, well, as obvious as the name - is "live".

But, hear me out.
Writing a stack for us newbies is fun and exciting. And from what has been 'talked' about with respect to "LiveCode" - is one of the goals of LiveCode - is to bring 'coding' to us non-programmers. I think I've heard about this in a few YouTube vids with Kevin Miller....

So here is my point. You've written a 'stack' (yea, I know HyperCard, MetaCard, and Runrev are nonliving, 'zombie' like). All is good with the stack and code. You save it as a stand alone or "app" and "things" change.... Bummer.

Solution - change the code ("coder beware!".)

Solution - "write a 'splash' stack" that opens the LiveCode file or your stack.... Well if this is the case, why not have a "Player" that is the 'universal splash stack' that has limited use for us nonprogrammers. Before you say "No" think about it. This may be a way to encourage more to get involve with LiveCode - increase ease of use... You create/write a stack. Save it. Use it as is... What you write/code is what you get, no surprises... This may be a way for us nonprogrammers to use our stacks ourselves (or in the classroom) and not have to worry about commercial or similar distributions (yes, we still can do that by always using a stack as a file and not an exe, which is what I do....). Then, we can slowly work our way to making an 'application' a real 'application' not a 'file' opened/read/manipulated by the 'LiveCode Player'. (It could be that when saving the file as an app, a setting allows you to automatically have an splash stack open your file.... just a "nonprogrammer-idea".)

FYI, I have been a supporter for LiveCode/RunRev for years. I contributed to KickStart too.


Thanks ... from my side of the pond...
John Burnett
jburnet3@twcny.rr.com
jsburnett

This is a duplicate of the post you made here: http://forums.runrev.com/viewtopic.php? ... 988#p94988

Would you like me to delete that one?

Would keep this one, since the other post is tacked onto an old message thread... Just my thought however

Thanks for your reply.

I think your making a new one here was a good move. It keeps the thread necromancy in check, and provides its own space for a topic worthy of discussion.

Accordingly, I've deleted the duplicate in the other thread, and the two messages there about whether it should be deleted. We'll let the dead remain dead, and see where this discussion takes us among the living.

With the forum housekeeping out of the way, we can get back on topic:

jsburnett wrote:So here is my point. You've written a 'stack' (yea, I know HyperCard, MetaCard, and Runrev are nonliving, 'zombie' like).

Actually, of those only HyperCard is dead. MetaCard, Revolution, and LiveCode are all the same product, evolving over time through new versions.

All is good with the stack and code. You save it as a stand alone or "app" and "things" change.... Bummer.

True, but if we want to assess the scope of the problem it may be helpful to review its history:

HyperCard was able to produce standalones that could modify themselves because of a feature unique to the old, long-defunct Mac Classic OS: a dual-fork file system. This allowed HC's code to live in the "resource" fork, while the stack was in the data fork.

No multi-platform tool could do that because most OSes use a single-fork file system. And even on OS X, the resource fork is still supported but only grudgingly; Apple long ago marked resource fork APIs as deprecated, and we can expect them to replace HFS+ with something more modern in the coming years, after which resource forks will disappear entirely.

Since OS X 1.0, all popular OSes use as single-fork file system. And that was 13 years ago - Apple killed HyperCard years earlier.

For those of us who cut our teeth on HC, when we first got started with LC we had the expectation that standalones could modify themselves as they had in HC, and had to learn that no modern OS will allow it.

But how many of us are there?

Even in its heyday, in most orgs I worked with there were only one or two scripters who actually made apps; everyone else used the apps those people made.

Since then most HC developers moved on to something else a long time ago - mostly JavaScript/HTML, and some went to Director or Flash or something else, leaving some of the rest of us to find our way to LC.

So in terms of number of users who would expect this, we're a subset of LC users who were building standalones in HyperCard more than 15 years ago.

Most folks I meet don't even know what HyperCard was.

Many newcomers to LiveCode have used at least one other development tool before, and very few have ever even seen an app that can modify itself.

Given the seemingly small number of people with this expectation, the folks at RunRev apparently felt it was sufficient to put a bold note in a big purple-colored box so it stands out in the section of the User Guide on building standalones (p299), which reads:

Note: A stack file directly attached to a standalone application cannot have changes saved to it. This stack is bound directly to the executable file that runs. The OS locks an executable file while it is running. If you want to save changes in your standalone application, split your stack up until multiple files. A common technique is to create a "splash screen" stack that contains a welcome screen and then loads the stacks that make up the rest of your application. These stacks are referenced as stackFiles on this pane in the standalone settings screen. It is thus possible to automatically update these component stacks, or to save changes to them. You may also want to consider creating preference files in the appropriate location on your end user's system (see the specialFolderPath function and query/setRegistry functions for more information).

But perhaps RunRev underestimated the scope of affected people. The subset of the subset of HC users from 15 years ago aside, how pervasive is this expectation? Should there be other places where this is called out?