LiveCode Forums.

This time under windows…



Happy Feet is the name of the main stack, and is where the script is located. tsource is a valid filepath; neededPath is a valid folderpath. If I step through the script in the debugger, the file is copied without script error.

What have I missed this time?



-thanks

post some code so we could take a look..

Thanks… but I found this in the doc:

Note: In a standalone application the Common library is implemented as a hidden group and made available when the group receives its first openBackground message. During the first part of the application's startup process, before this message is sent, the revCopyFile command is not yet available. This may affect attempts to use this command in startup, preOpenStack, openStack, or preOpenCard handlers in the main stack. Once the application has finished starting up, the library is available and the revCopyFile command can be used in any handler.

on rant
so revCopyFIle does not work in sandboxed apps in OS X because it uses AppleScript
and it doesn't work in Windows on startup
which seems to be the most likely time a developer needs to install writable files
WHAT!!! the RR team can't write a couple of real copyFile routines
end rant

There are many ways to copy files, on each of the platforms RunRev supports. At the time they implemented their use of AppleScript, it was an expedient way to leverage all the benefits the Finder provides for handling the unusual behavior of the OS X file system, and there was no way for them to know that Apple would reverse a 20-year tradition by suddenly disallowing their own AppleScript.

Now that this is known I believe they're working on a replacement.

In the meantime you can use the read and write commands to copy files that don't require special privileges. Those that do could be handled by shell, but unfortunately Apple has made many shell calls verboten in sandboxing as well.

Thanks… I had already done that on the Mac side of things to avoid AppleScript. I'll use the same code on Windows in lieu of the simpler (and disfunctional) revCopyFIle.

On Windows revCopyFile uses a one-line call to shell. Are you sure your path is correct? It may be useful to get some details so we can determine if the shell's "copy" command is somehow differently implemented on your system so we can file a bug report.

Paths are correct, and the command executes without error when stepped thru in debug.

Did you read my post above where I quote the documentation?

rrBUSS9EE wrote:Did you read my post above where I quote the documentation?

I just reviewed it and it seems accurate, so I'm just trying to figure out how it's "dysfunctional".

With all due respect… I would assume a lot of LC developers have a need to copy "writable" files to appdata/document locations if their app is to save data. IMHO, it is most likely for folks to want to do this at startup (preOpenStack), so that first run apps have access to this/these files, whether they be database templates, other stacks, or whatever.

It seems to me this is what revCopyFile was intended for, but it does not work within this context. While I understand there are workarounds for this (I have used many in my short stint with LC), it doesn't negate the fact that LC is the only high level authoring tool that I have used (I have used quite a few over the last 20 years) that does not include a legitimate fileCopy routine that works without caveats.

So while I know I can always push my gasoline powered automobile down the road as the "LC station" only offers diesel, I'd prefer not to.

Now I'm just confused. I had thought the issue was Windows, which you've since said is working well. And for Mac, we've covered how you can use two lines with "read" and "write" to replace the one-line call to revCopyFile to get your work moving forward while they update that for the sandboxing requirement that went into effect this month.

Personally, I've never used revCopyFile so this has never been an issue for me, and since this is the first complaint here on this it may be that most use the engine's native "read" and "write" commands instead of "revCopyFile", which might explain why it hasn't been on RunRev's front burner.

Just trying to see if there's anything here I may be able to help with. If you've encountered a challenge in using the tool to accomplish a goal, I may be able to help. If your interest lies elsewhere I may not.

FourthWorld wrote:Now I'm just confused.

I'll try and clear that up for you. RevFileCopy results in a handler not found error on both Mac OS (regardless if in the sandbox or not) and Windows when run from preOpenStack. And probably openStack as well. And while read/write may be a workaround for some files (flat), it is not for others.

Maybe we can just agree it is broken and hopefully a fix is forthcoming.

rrBUSS9EE wrote:Maybe we can just agree it is broken and hopefully a fix is forthcoming.

Actually, I think this would fall under the category of "design decision" rather than a bug.

While revCopyFile may be enhanced to avoid using AppleScript on sandboxed Mac systems, your clarification describes a very different problem: the load sequence for the Rev libraries.

The sequence of engine boot messages is:
startup
preOpenStack
preOpenBackground
preOpenCard
openStack
openBackground
openCard

If you look at the script for the group that gets included in standalones ("revLibraries" in the stack "revLibrary.rev") you'll find it calls revLoadLibraries from the preOpenStack, preOpenBackground, and preOpenCard messages (presumably this redundancy is for fault tolerance among a wide variety of user scripting setups).

You can verify this sequence by making a stack, putting some arbitrary controls in a group, and then putting this in the stack script:

on preOpenStack
Report the params && the name of me
pass preOpenStack
end preOpenStack

on preOpenCard
Report the params && the name of me
pass preOpenCard
end preOpenCard

on preOpenBackground pBgID
Report the params && the name of me
pass preOpenBackground
end preOpenBackground

on openCard
Report the params && the name of me
pass openCard
end openCard

on openBackground pBgID
Report the params && the name of me
pass openBackground
end openBackground

on openStack
Report the params && the name of me
DumpReport
pass openStack
end openStack

on Report s
global gReportData
put s& cr & the backscripts &cr&cr after gReportData
end Report

on DumpReport
global gReportData
put gReportData into url ("file:"& specialFolderPath("desktop") & "/messagelog.txt")
end DumpReport

In the card script you'll put the same message handlers, omitting the call to "DumpReport" in the openCard handler since we only want that called at the end of the boot sequence.

Before building, be sure to set the option to manually include libraries rather than rely on the standalone builder looking to see if your app needs them, since of course our app has so little code that it won't actually need them.

Running the resulting standalone here gives me a log file that shows the backscripts empty for only the card script's handling of the preOpenStack message, with all others showing the RevLibrary backscripts in place.

The docs are probably just being a bit conservative in their description of affected messages, given the wide range of unpredictable things people do with LC. But as the sample script above shows, it seems that the handlers in the revLibrary scripts should be available to your stack script using any of the messages listed above, and even to your card script before it using any but preOpenCard.

There are no preOpen* handlers in any of the cards. In fact, the only one in the entire stack is a preOpenStack handler in the stack script.

What happens if you change your preOpenStack handler to openStack?