Standalone not saving stack file
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Standalone not saving stack file
Following wonderful suggestions posted elsewhere by Klaus and others, I'm using a LC stack file (independent of the main stack) as a template. The app makes a copy of the template, then saves to disk the input stored in that new file.
(BTW, I'm recreating from scratch an insanely complicated 30-year old Windows-only app, which my client wants -- for better or for worse -- to mimic the Windows app as closely as possible.)
In the IDE -- which I'm running on a Mac under macOS 10.6.8 -- everything works just fine: On my Mac, the template is copied, the input is saved to disk as that LC stack file, and the entries can be redisplayed when the app reopens that file. All as expected. Moreover, when I run the Windows standalone on an old Windows Vista laptop, it similarly works as expected (i.e., the separate data file stack is saved and can be reloaded as intended).
The *problem* is that -- unlike the Windows app -- the macOS standalone fails to copy the template to disk, even though this works fine when running in the IDE. The app just stalls at that point.
Inasmuch as I'm still running the ancient macOS 10.6.8, this was unexpected. I'd anticipated having to grapple with problems with the security restrictions imposed by more recent versions of macOS, but never expected that this would be a problem as far back as 10.6.8.
I've previously had no problem with my other apps in saving preference files to the AppSupport folder and saving PDF files to the Documents folder. Still, this failure occurs even when the standalone is run from a folder on the internal hard disk other than the presumably protected Applications folder.
I've created these standalones using the most recent stable version of LC 8. I welcome any of your insights. Thanks.
jeff k
(BTW, I'm recreating from scratch an insanely complicated 30-year old Windows-only app, which my client wants -- for better or for worse -- to mimic the Windows app as closely as possible.)
In the IDE -- which I'm running on a Mac under macOS 10.6.8 -- everything works just fine: On my Mac, the template is copied, the input is saved to disk as that LC stack file, and the entries can be redisplayed when the app reopens that file. All as expected. Moreover, when I run the Windows standalone on an old Windows Vista laptop, it similarly works as expected (i.e., the separate data file stack is saved and can be reloaded as intended).
The *problem* is that -- unlike the Windows app -- the macOS standalone fails to copy the template to disk, even though this works fine when running in the IDE. The app just stalls at that point.
Inasmuch as I'm still running the ancient macOS 10.6.8, this was unexpected. I'd anticipated having to grapple with problems with the security restrictions imposed by more recent versions of macOS, but never expected that this would be a problem as far back as 10.6.8.
I've previously had no problem with my other apps in saving preference files to the AppSupport folder and saving PDF files to the Documents folder. Still, this failure occurs even when the standalone is run from a folder on the internal hard disk other than the presumably protected Applications folder.
I've created these standalones using the most recent stable version of LC 8. I welcome any of your insights. Thanks.
jeff k
Re: Standalone not saving stack file
Hi Jeff,
Best
Klaus
could you please post (the relevant parts of) your script?The *problem* is that -- unlike the Windows app -- the macOS standalone fails to copy the template to disk, even though this works fine when running in the IDE. The app just stalls at that point.
Best
Klaus
Re: Standalone not saving stack file
Klaus --
Thanks for your kind reply. It wasn't my intent that you troubleshoot my errant code, but I'm sure you can spot my stupid errors.
The thing is that my colleague-now-client is insisting that the Mac version be as similar as possible to his Windows version. (I've been trying to persuade him for 30 years to create Mac versions of his apps, but it wasn't until his stalwart VisualBasic programmer retired that I got the job.) So the LC data template is a free-standing file in the app folder -- just as in Windows -- and newly-created copies of that template must be stored as data files within a subfolder.
Thinking on into the future, the macOS probably will require that data files be stored in the Documents folder.This is a hard sell because the client is so Windows-centric, yet probably inevitable. (I probably can do an if-then to handle Mac vs. Windows specific code in the future.)
The current routine and subroutines are called when the user clicks on a button in the modal window into which demographic info has been entered. There seems to be no problem until step (i) of the subroutine "doCreateClientFile" completes, inasmuch as the short pathname of the cloned data file displays correctly in the main window at the end of the previous subroutine (h).
Why this bug in my app occurs only in the Mac standalone remains a mystery.
Thanks much!
jeff k
P.S. The app is named "Hermann" because it is designed to enable scoring of Hermann Rorschach's famous projective inkblot test.
Thanks for your kind reply. It wasn't my intent that you troubleshoot my errant code, but I'm sure you can spot my stupid errors.
The thing is that my colleague-now-client is insisting that the Mac version be as similar as possible to his Windows version. (I've been trying to persuade him for 30 years to create Mac versions of his apps, but it wasn't until his stalwart VisualBasic programmer retired that I got the job.) So the LC data template is a free-standing file in the app folder -- just as in Windows -- and newly-created copies of that template must be stored as data files within a subfolder.
Thinking on into the future, the macOS probably will require that data files be stored in the Documents folder.This is a hard sell because the client is so Windows-centric, yet probably inevitable. (I probably can do an if-then to handle Mac vs. Windows specific code in the future.)
The current routine and subroutines are called when the user clicks on a button in the modal window into which demographic info has been entered. There seems to be no problem until step (i) of the subroutine "doCreateClientFile" completes, inasmuch as the short pathname of the cloned data file displays correctly in the main window at the end of the previous subroutine (h).
Code: Select all
-- SCRIPTS INCLUDED IN THE STACK “ClientDlg”
-- declare script variables to simplify checking entries and communicating constructed names
local sClientFileName -- to store the constructed client file name
local sMissingEntry -- to facilitate checking that demographic info was entered
-- *** MAIN ROUTINE TO PREPARE TO RECORD A NEW CLIENT TEST FILE ***
-- called by the "Begin Data Entry" button of the New Client dialog
-- creates a new client file and fills in the demographic data
on doPrepForDataEntry
-- (1) first check that needed demographic info has been entered
doCheckClientInfo -- subroutine (1)
-- exit the routine if script local variable flags any essential data missing
if sMissingEntry is true then
exit doPrepForDataEntry
end if
-- (2) copy the template to ClientData folder and rename this as the client file
doCreateClientFile -- subroutine (2)
-- (3) concatenate names of the client and examiner for entry into client file
doPrepareNames -- subroutine (3)
-- (4) open the new client file invisibly and populate the demographic fields
doPopulateClientFile -- subroutine (4)
-- (5) close the New Client entry window
set the destroyStack of stack "ClientDlg" to true
close stack "ClientDlg"
end doPrepForDataEntry
-- SUBROUTINES TO PREPARE THE NEW TEST...
-- (2) CREATE THE NEW CLIENT FILE
on doCreateClientFile
-- (a) declare local variables
local tThisMainStackPath -- path to the Hermann application file
local tThisMainAppFolderPath -- path to the folder containing the app
local tClientFolderPath -- path to the ClientData folder into which the client file must be saved
local tThisTemplatePath -- path to the template to be copied to the client folder
local tThisClientPath -- path to the template actually copied to the client folder
local tNewFileName -- to hold newly constructed filename for the client file
local tRenamedFilePath -- final path to the client file
-- (b) get the full path to the Hermann app
put the effective filename of this stack into tThisMainStackPath
-- (c) construct the path to the folder in which Hermann resides
put tThisMainStackPath into tThisMainAppFolderPath
set the itemdelimiter to slash
delete last item of tThisMainAppFolderPath
-- (d) construct the path to the ClientData subfolder
set the itemdelimiter to slash
put tThisMainAppFolderPath & slash & "ClientData" into tClientFolderPath
-- (e) construct the path to the template (which is a free-standing LC file)
set the itemdelimiter to slash
put tThisMainAppFolderPath & slash & "ClientTemplate.hrm" into tThisTemplatePath
-- (f) actually copy the template file to the client folder
revCopyFile tThisTemplatePath, tClientFolderPath
-- (g) create full path to this copy of the template
set the itemdelimiter to slash
put tClientFolderPath & slash & "ClientTemplate.hrm" into tThisClientFilePath
-- (h) call subroutine to assemble a name for the newly-created data file
-- the constructed name is saved to script variable sClientFileName
-- the short file name is also displayed in a field of the main window
doConstructNewFileName
-- (i) create final path to new client data file
set the itemdelimiter to slash
put tClientFolderPath & slash & sClientFileName into tRenamedFilePath
-- rename file tThisClientFilePath to tRenamedFilePath
put url("binfile:" & tThisClientFilePath) into url("binfile:" & tRenamedFilePath)
-- store the client file path to a custom property in the main stack
set the cClientFilePath of stack "Hermann" to tRenamedFilePath
-- delete the template file originally copied to the ClientData folder
set the destroyStack of stack tThisClientFilePath to true
delete stack tThisClientFilePath
delete file tThisClientFilePath
end doCreateClientFile
Thanks much!
jeff k
P.S. The app is named "Hermann" because it is designed to enable scoring of Hermann Rorschach's famous projective inkblot test.
Re: Standalone not saving stack file
Hi Jeff,
not sure, but I think you are trying to copy a file TO the macOS Application folder**,
which only users with ADMIN privileges are allowed to do.
...
put the effective filename of this stack into tThisMainStackPath
...
If THIS stack resides inside of the mac application bundle then this will fail most of the time, see above.
And yes, you will need to save things in the user Documents folder on a Mac or better in:
specialfolderpath("preferences")
I ususally use functions that return pathnames so I can differ between the platforms in the function.
Like this one for the appropriate prefs folder:
Best
Klaus
P.S.
We have a very active forum member named Hermann, check his great stacks in the "Raspberry Pi" forum,
so thanks for your explanation of your app's name
not sure, but I think you are trying to copy a file TO the macOS Application folder**,
which only users with ADMIN privileges are allowed to do.
...
put the effective filename of this stack into tThisMainStackPath
...
If THIS stack resides inside of the mac application bundle then this will fail most of the time, see above.
And yes, you will need to save things in the user Documents folder on a Mac or better in:
specialfolderpath("preferences")
I ususally use functions that return pathnames so I can differ between the platforms in the function.
Like this one for the appropriate prefs folder:
Code: Select all
function fPrefsfolder
switch the platform
case "MacOS"
put specialFolderPath("preferences") into spfp
break
case "Win32"
if the systemversion contains "NT" then
put specialFolderPath(35) into spfp
### For all users!
### specialfolderpath(26) = for the current user only!
else
## Up to WinXP
put specialfolderpath("system") into spfp
end if
break
default
## Linux
put $HOME into spfp
break
end switch
return spfp
end fPrefsfolder
Klaus
P.S.
We have a very active forum member named Hermann, check his great stacks in the "Raspberry Pi" forum,
so thanks for your explanation of your app's name
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Standalone not saving stack file
Hermann goes by the moniker "-hh" (note the "-") if you want to search for him.
Craig Newman
Craig Newman
Re: Standalone not saving stack file
Hi Klaus --
First, thanks for reposting here the code snippet for your fPrefsfolder function. Although I'd seen it before elsewhere, this saves me from having to track it down when time to add cross-platform code for saving a preferences file.
You're right that as currently written the app would try to copy the template -- a free-standing LC stack file, not in the application bundle -- to a subfolder of the Hermann app folder in the macOS Applications folder. I understand that this is forbidden in recent versions of the macOS and will need to be corrected. (In my own Mac apps, I write files only to the Documents and Application Support folders, which using specialfolderpath works just fine.) But the author wanted my LC version of his Hermann app to look just like the original VisualBasic version, with everything located within the app folder. This apparently works in Windows standalones, which are what I must provide in order for him to review my progress.
I wish that Apple's restrictions accounted for the problem with the macOS standalone, but this is not the case: Even when the standalone resides in a folder outside the Applications folder -- so, at least in macOS 10.6.8, presumably not subject to those restrictions -- it still fails to create a copy of the template file, despite the fact that the copying works correctly when the code is run from within the IDE.
There is apparently some bug in the last few steps of the code.
I definitely will inform my colleague that it's simply not possible to emulate the file/folder structure employed in Windows in recent versions of the macOS. He probably will relent, only because most of our grad students nowadays use Macs and have no problem understanding that documents are saved to the Documents folder. So I'll have to invent code to handle saving the client data files (LC stacks) to the platforms differently.
I'd stupidly agreed to do this project for $3500 US, mainly because the author intends to give away the app for free in order to promote his own books on the Rorschach test. (At 200 hours and still counting, this was a terrible decision -- considering, for example, that the main stack page alone involved coding/coordinating approximately 120 buttons, divided into a number of groups.)
Thanks again for addressing my issue.
jeff k
P.S. Thanks to Klaus and Craig for references to "Raspberry Pi." As an educator, it seems a wonderful K-12 learning platform. But it's not something employed among the professional and doctoral-student clinical psychologists for whom my apps and app conversions are intended).
First, thanks for reposting here the code snippet for your fPrefsfolder function. Although I'd seen it before elsewhere, this saves me from having to track it down when time to add cross-platform code for saving a preferences file.
You're right that as currently written the app would try to copy the template -- a free-standing LC stack file, not in the application bundle -- to a subfolder of the Hermann app folder in the macOS Applications folder. I understand that this is forbidden in recent versions of the macOS and will need to be corrected. (In my own Mac apps, I write files only to the Documents and Application Support folders, which using specialfolderpath works just fine.) But the author wanted my LC version of his Hermann app to look just like the original VisualBasic version, with everything located within the app folder. This apparently works in Windows standalones, which are what I must provide in order for him to review my progress.
I wish that Apple's restrictions accounted for the problem with the macOS standalone, but this is not the case: Even when the standalone resides in a folder outside the Applications folder -- so, at least in macOS 10.6.8, presumably not subject to those restrictions -- it still fails to create a copy of the template file, despite the fact that the copying works correctly when the code is run from within the IDE.
There is apparently some bug in the last few steps of the code.
I definitely will inform my colleague that it's simply not possible to emulate the file/folder structure employed in Windows in recent versions of the macOS. He probably will relent, only because most of our grad students nowadays use Macs and have no problem understanding that documents are saved to the Documents folder. So I'll have to invent code to handle saving the client data files (LC stacks) to the platforms differently.
I'd stupidly agreed to do this project for $3500 US, mainly because the author intends to give away the app for free in order to promote his own books on the Rorschach test. (At 200 hours and still counting, this was a terrible decision -- considering, for example, that the main stack page alone involved coding/coordinating approximately 120 buttons, divided into a number of groups.)
Thanks again for addressing my issue.
jeff k
P.S. Thanks to Klaus and Craig for references to "Raspberry Pi." As an educator, it seems a wonderful K-12 learning platform. But it's not something employed among the professional and doctoral-student clinical psychologists for whom my apps and app conversions are intended).
Re: Standalone not saving stack file
Hi Jeff,
I recenbtly encountered a strang "not a bug, but a (Mac) feature" thing, maybe your problem is related to this somehow?
http://quality.livecode.com/show_bug.cgi?id=19686
And yes, you are right, Mac users KNOW that the Application folder is TABOO!
VB Developers on Windows abviously don't.
Best
Klaus
I recenbtly encountered a strang "not a bug, but a (Mac) feature" thing, maybe your problem is related to this somehow?
http://quality.livecode.com/show_bug.cgi?id=19686
And yes, you are right, Mac users KNOW that the Application folder is TABOO!
VB Developers on Windows abviously don't.
Best
Klaus