Re: Custom Property to store data in a standalone ap
Posted: Sun Apr 19, 2015 2:41 am
The foregoing discussion raises a couple of questions in me:
So we have a splash stack, located in specialFolderPath("engine"), which loads the main stack, located in specialFolderPath("documents"), and closes itself. We can now store data as custom properties of (objects in) the main stack.
1. If we store data in the main stack, how do we make sure that this data is transferred to the replacement main stack when we update the app? Even if we could, is it not cleaner to keep the user data apart form what will be updated/replaced?
2. In the latter case, if we still wanted to save some of the information as custom properties in a stack (for the reasons given by others earlier in this thread), is it not better to create a third stack (called, say, "dataStack") which can hold the information that should persist across app updates? If we were to do this, what would be the guidelines as to what kind of data should be put into stacks and which ones to save in files?
I suspect it would be better to save media (audio and video, not sure about images) as files but keep text and numeric data in the stack? Or, since working memory is scarcer than storage memory, keep data that is frequently referred or updated in the stack and those which are large, infrequently referred, or streamed, in the form of files.
Does any of this make sense?
Regards,
Sri
P.S. An unrelated question: If the splash stack opens the main stack and then closes itself (as Newbie4 has suggested), wouldn't the program close, since the executable has exited?
So we have a splash stack, located in specialFolderPath("engine"), which loads the main stack, located in specialFolderPath("documents"), and closes itself. We can now store data as custom properties of (objects in) the main stack.
1. If we store data in the main stack, how do we make sure that this data is transferred to the replacement main stack when we update the app? Even if we could, is it not cleaner to keep the user data apart form what will be updated/replaced?
2. In the latter case, if we still wanted to save some of the information as custom properties in a stack (for the reasons given by others earlier in this thread), is it not better to create a third stack (called, say, "dataStack") which can hold the information that should persist across app updates? If we were to do this, what would be the guidelines as to what kind of data should be put into stacks and which ones to save in files?
I suspect it would be better to save media (audio and video, not sure about images) as files but keep text and numeric data in the stack? Or, since working memory is scarcer than storage memory, keep data that is frequently referred or updated in the stack and those which are large, infrequently referred, or streamed, in the form of files.
Does any of this make sense?
Regards,
Sri
P.S. An unrelated question: If the splash stack opens the main stack and then closes itself (as Newbie4 has suggested), wouldn't the program close, since the executable has exited?