(07-26-2021, 12:17 PM)stamatis Wrote:

Quote:I had only included mergJSON with initial builds (as per the website). This seemed to fail, and resolved when i included the standard JSON library as well. Are both required or is this a coincidence?

CanelaDB does not need the standard JSON library to be included when making your standalone. I verified that LCM does not have it included. 

Quote:To ensure connectivity with liveCloud include the ‘canelaDB’ folder as an in the standalone settings ‘copy files’ section (ie should be available in specialFolderPath("resources"). On first run, this folder is copied to the user’s Documents folder (writeable location), along with he mainstack that is launched form the splash stack.
However when building a mac app, the locked libraries are causing the standalone build to fail with the error ‘cannot open output files’ or some such. I can work around this by removing the the CanelaDB folder from the ‘Copy Files’ section of the standalone settings, build the app and then manually copy this to <show app package contents>/Contents/Resources/_MacOS/
Is there a better way to do this?

This sounds like a LiveCode standalone builder bug. I'll give it a try and report back what I find. By chance, are you using the "Search for required inclusions when saving the standalone application" when building? LiveCode will not be able to read through encrypted files to see what is inside. They should fail nicely and continue to work in my opinion. Maybe it is not doing that gracefully.

Quote:On running a the same standalone on Mac and Windows, it works fine on Mac, but on Windows it crashes - after some head scratching it seems that the checksum library checks on Mac work fine but throw an error on Windows. I’ve worked around this by commenting out the checksum library checks - the app works beutifully and will be used in a very trusted environment so that’s fine, but it’s obviously not desirable otherwise.
Can multiple checksums be correct (ie should i have checksum that works for both mac and win, unlike the one i have now that only works for mac)? Or do i need to derive a Windows checksum and include a platform check in the library checks?

The checksums should work for both platforms. After all, LiveCloud Manager relies on identical checksums for both platforms. It uses the same libraries we output when you do an export toolkit. Is it possible you are not using the same libraries for both platforms? Maybe an older version is being used on the Windows side?

-Mark

(07-27-2021, 01:12 AM)mark_talluto Wrote:

(07-26-2021, 12:17 PM)stamatis Wrote:

Quote:I had only included mergJSON with initial builds (as per the website). This seemed to fail, and resolved when i included the standard JSON library as well. Are both required or is this a coincidence?

CanelaDB does not need the standard JSON library to be included when making your standalone. I verified that LCM does not have it included. 

Quote:To ensure connectivity with liveCloud include the ‘canelaDB’ folder as an in the standalone settings ‘copy files’ section (ie should be available in specialFolderPath("resources"). On first run, this folder is copied to the user’s Documents folder (writeable location), along with he mainstack that is launched form the splash stack.
However when building a mac app, the locked libraries are causing the standalone build to fail with the error ‘cannot open output files’ or some such. I can work around this by removing the the CanelaDB folder from the ‘Copy Files’ section of the standalone settings, build the app and then manually copy this to <show app package contents>/Contents/Resources/_MacOS/
Is there a better way to do this?

This sounds like a LiveCode standalone builder bug. I'll give it a try and report back what I find. By chance, are you using the "Search for required inclusions when saving the standalone application" when building? LiveCode will not be able to read through encrypted files to see what is inside. They should fail nicely and continue to work in my opinion. Maybe it is not doing that gracefully.

Quote:On running a the same standalone on Mac and Windows, it works fine on Mac, but on Windows it crashes - after some head scratching it seems that the checksum library checks on Mac work fine but throw an error on Windows. I’ve worked around this by commenting out the checksum library checks - the app works beutifully and will be used in a very trusted environment so that’s fine, but it’s obviously not desirable otherwise.
Can multiple checksums be correct (ie should i have checksum that works for both mac and win, unlike the one i have now that only works for mac)? Or do i need to derive a Windows checksum and include a platform check in the library checks?

The checksums should work for both platforms. After all, LiveCloud Manager relies on identical checksums for both platforms. It uses the same libraries we output when you do an export toolkit. Is it possible you are not using the same libraries for both platforms? Maybe an older version is being used on the Windows side?

-Mark

Quote:The reason i even tried to add the locked files manually *after* the build is that i saw a post somewhere describing difficulties with locked files in this respect. 

Quote:It should be noted however that the Windows build is uneventful - it's just building for Big Sur that causes this problem for me. It's fine, just seems inelegant. But if you are able to build for Big Sur and including a folder containing the CanelaDB folder in the 'copy files' section please do let me know. (Mac OS 11.5, LC 9.6.2).

Quote:---- EDIT -----
I did go back and look at the checksums again; On Mac these but both CDB_Starter.lib and CDB_Header.lib pass the checksum test just fine.
On Windows, with identical lib files the check on CDB_Header.lib throws the error "Error, CDB_Header checksum did not match."
The checksums i derived are now identical to ones provided in stack script in the 'export toolkit' screen. 
When i get a chance I'll download the lib files again and see if replacing them makes any difference...

Quote:In the end i think i narrowed the problem down to the folder i was trying to include in the 'copy files' section. This folder contains the CanelaDB folder and the mainstack that is launched from the splash stack; the idea is that these are copied to the user's Documents folder on first run as a writeable location.

Quote:I discovered if i removed this folder and *only* added the canelaDB folder the standalone would build as expected; and I added the mainstack to the 'stacks' screen (just needed an extra line of code to make sure these both end up in the same place in the user's Documents folder). I also had to disable messages while building to prevent the mainstack from being launched during the build...

Quote:With regards to the checksum issue, I'll see if i can replicate the issue again on the target Windows system; keep in mind that LCM will not run on that system (there is something in the firewall that is I think blocking some function of spiceKit, as per a previous support email - missing it's launcher). Will the log file from my mac be any help?

Quote:--- EDIT --- 
I also forgot to mention that adding the files manually seemed to work OK when running it off my system. But when uploading the file and then re-downloading, MacOS would completely stop this from running stating that the app had been tampered with (which it had )  so i was very keen i could build this directly without having to manually add. Probably something that can be fixed when notarising etc, but easier not to have that issue!

1. 1. On the first run, copy the relevant parts of your project (everything after the starter stack) over to a safe and writeable place.

1. 2. Run the code from the writeable locationa. 

1.   a. Macs: specialFolderPath("asup")

1.   b. Windows: specialFolderPath(26)

1. 3. Have your pathing point to that location when the environment <> "development"

(07-30-2021, 11:19 PM)mark_talluto Wrote: Hi Stam,

You did everything correctly. The process of code-signing and notarizing is complicated. I can see that you navigated it well.

You can solve the problem you are experiencing by doing the following:

1. 1. On the first run, copy the relevant parts of your project (everything after the starter stack) over to a safe and writeable place.

1. 2. Run the code from the writeable locationa. 

1.   a. Macs: specialFolderPath("asup")

1.   b. Windows: specialFolderPath(26)

1. 3. Have your pathing point to that location when the environment <> "development"

Yep, developing for Apple has become more complex. All of our shipping apps use this method. LCM (Win version) is designed to be a portable app and thus does not use specialFolderPath(26). It instead writes to files and folders next to the .exe.

Should you decide to codesign your Windows apps, then SFP(26) will be useful. Our 2020 Vision product uses that location.

I hope this helps

-Mark