Read/write should not go to read only when saved as app

[sylvanr]

My feature request: Keep database functionality intact when saving as a standalone application or moving to iPhone simulator.

When I first stumbled across LiveCode, I was happy to see the similarities it had with the old Hypercard and was even more excited to see that it could actually open some of my old Hypercard stacks and with minimal modifications, those stacks could actually work in the runrev Livecode environment and maintain most of their functionality. The BIG disappointment came when I discovered that you lost a MAJOR portion of that functionality when you saved a stack in LiveCode as a standalone application or moved the stack into the iOS simulator. Wow, what a letdown!

For me, the most appealing aspect of Hypercard, and now LiveCode, is the ability to easily create read/write database applications, where the end user can add records, delete records and modify data. I suppose for some people, the ability to easily write a read only application is enough but for me, the ability to create a read/write database is 90% of what makes LiveCode appealing. It was a big disappointment to save to a standalone application or move to the iOS simulator, and find my database which was read/write before, was now read only. A read only application has some appeal and I will make use that, but it does not have nearly the appeal of an interactive read/write application.

If there was any one feature that I would want added to LiveCode, it would be the ability to save a standalone application, or move it to the iPhone iOS, and have it function exactly the same after saving as a standalone application as it did before saving it as a standalone application and retain ALL of it's read/write capabilities. For me, this seems to be a major flaw-that you lose those capabilities when you want to share your application. Livecode works fine as long as you don't need to share your application with anyone as a standalone application or as a iPhone app, but my main interest is being able to share read/write databases as iPhone apps.

I have read some of the work arounds that others have suggested in the database and iOS forums, for saving preferences or small amounts of data in a file outside of the application but these work arounds are quite a bit more complicated and much less robust than just having a stack function the same after saving as standalone as before saving as standalone. Maybe there is something I am missing? Before saving as an application, an end user can seamlessly add or delete records and modify data, but after saving as a standalone or moving to iPhone iOS, an end user can only save a few preferences or a few lines of data or save a few modifications of data from records that already exist, but are not able add their own records?… and the data files are saved outside the application and require additional programming to get it there?

Any feedback, help, enlightenment, clarification, or advise will be appreciated. I do hope that whoever is working on LiveCode is looking at a way to retain the same capabilities AFTER saving as standalone as BEFORE saving as standalone.

Thanks.

[Klaus]

Hi sylvanr,

I understand your issues, but I am afraid this will never happen!

1. HyperCard was a VERY special kind of beast and it only run on a Mac.
"Special" in that way, that is saved everything automatically and it was the ONLY app I know that did this at that time.
Hypercard used a special mechanism (technical stuff I do not understand completely) which made it possible to use it
as a database with 10,000 or more entries.
Since Livecode loads a stack completely into RAM, this will not work in Livecode as one might want.
2. LiveCode is NOT Hypercard although there are lots if similarities in usage and snytax.
3. Hypercard is DEAD! Get used to this thought
4. Standalones cannot (and problably will never) save themselfes. Period!

If they did, there would be a permission problem on modern operating systems, since they are in fact multi-user
operating systems and only a user with administrator rights can write to the "Application" folder!

So It is up to you as a programmer to not look back but go ahead and save your data somehow in a place where
you have definitvely write permissions!

There are many ways to do so, and I will post a solution that you will probably like later this day in the
"database on iPhone" thread, that you started

Best

Klaus

[FourthWorld]

Well said, Klaus.

sylvanr, one thing to keep in mind with HC's page-from-disk behavior is that such systems are inherently less robust than write-all-at-once systems like LiveCode. Compare the frequency of corrupt HC stacks to LiveCode files and this becomes clear. Corruption isn't impossible in LiveCode but it's extremely rare, esp. when compared to the many messages I used to see in alt.comp.sys.hypercard about error 5454.

As for saving data, HC apps were able to save to themselves because back in the olden days Mac OS had a dual file system, which put executable code in the resource fork while allowing the data fork to remain writable. In OS X, as well as Windows and Linux and most other OSes, the OS simply prevents the executable from modifying itself. This isn't so much a LiveCode thang as an OS thang.

But it's easy enough to work with, just as all modern Mac apps do - check out the helpful tips in this article by Sarah Reichelt at LiveCode Journal:

http://livecodejournal.com/tutorials/sa ... ution.html

[sylvanr]

Thanks, Klaus, I will look for your solutions tonight when I get home from work.

Richard, I have been trying to get Sarah Reichelt's suggestions to work for the last couple of days and was up until three this morning trying to do so again. Her "Saving sub-stacks" solution is the one I have focused on for the most part as it seems like it would be the best solution for my purposes if I could get it to work. I had been able to save a few fields of data to a preference file with a write button and then recover that data with a read buttons but I couldn't see how that would be practical for multiple records. The saving to a preferences file solution also didn't seem to allow the end user to add new cards/records where it seems like the sub stack solution should allow them to do so?

With the Sarah Reichelt's substack solution, I have been able to get a mainstack with a substack into the iOS simulator and the mainstack opens the stubstack but changes are still not saved when I close the stack. I'm not sure what I am doing wrong? In Sarah's example, she uses several substacks of the mainstack. I am only trying to save one substack. I keep trying various ways of doing it, hoping that trial and error will finally lead me to the solution but nothing has worked so far. I accept that there still may be something I am doing wrong and will keep trying but any light that could be shed on her substack solution would be appreciated or let me know if that is really not the best solution. What am I missing here?? The substack solution should allow the user to add cards and modify data and those changes should automatically be saved when closing the stack in the simulator the same as when they are automatically saved before moving to the simulator???

[BvG]

Code: Select all

on closeStackRequest
  save this stack
  pass closeStackrequest
end closeStackRequest

Watch out for unfamiliar cases like:

user (or os) force quits app
substacks sends a closestackrequest (if handler is in mainstack)
some particularities with quitting an app on certain oses where closestackrequest is not sent (sorry no details, long time since i tested it)

also see this lesson on how to do the "launcher" app (it's a simplified example):
http://lessons.runrev.com/spaces/lesson ... plication-