revcopyfolder problem
ron barber
runrevron at gmail.com
Wed Aug 24 15:12:05 EDT 2011
Thanks Ken, Jacque,
I know the result indicates an applescript problem, I should have
clarified a bit by asking if the user could do something in his system
that would cause the applescript problem?
Jacque the problem sounds similar. My app creates a folder in the
library/app support folder. That was failing so I sent him a stack
that tried to write a simple folder to the support folder without all
the other stuff the original app was doing. It failed but reported its
progress to the point of using revcopyfolder. It created a folder and
reported the existence of it afterwards. Next it tries to
revcopyfolder from a folder stored in the .app package but it fails. I
also tried writing to the defaultfolder where the simple test app was
and the same result as writing to app support - execution error.
Based on what you are seeing, perhaps the original report of the
existence of the folder is incorrect so naturally the following call
to revcopyfolder fails. The problem would then be in the call 'create
folder'. Should we be looking there instead?
Thanks
Ron
On Wed, Aug 24, 2011 at 2:30 PM, J. Landman Gay
<jacque at hyperactivesw.com> wrote:
> On 8/24/11 1:05 PM, Ken Ray wrote:
>>
>> On Aug 24, 2011, at 12:10 PM, ron barber wrote:
>>
>>> Hi,
>>> A user is reporting a problem with my software and I have traced it
>>> back to an opening call to revcopyfolder. He is on a Mac 10.6. I sent
>>> him two other stacks that simply call revcopyfolder and they fail,
>>> returning execution error in the result. The paths check out and I
>>> have never had a report like this before. Can anyone suggest what
>>> might be going on? I know revcopyfolder uses Applescript but could
>>> that be the cause?
>>
>> Absolutely - the result "execution error" only comes from trying to
>> run an AppleScript that has a problem.
>
> There may be something wonky going on with folders in 10.6 and maybe 10.7.
> I've had some weird experiences that are not always reproducible.
>
> Part 1: I have a function with a simple repeat loop that just looks for a
> uniquely numbered folder name so I can create a new numbered folder the same
> way the standalone builder does. It works fine on my iMac. If I move the
> stack to my MacBook Pro (same OS, same version of LiveCode) it fails the
> "there is a folder" check. The same thing happened to one of my testers.
>
> For example, I want a folder named "myfolder" and if one exists, append a
> number until there is no folder with that name. Assume there's already an
> existing folder named "myfolder". The next time I call the function and it
> hits this line:
>
> if there is a folder ("myfolder" & x) then...
>
> it should return false because "myfolder 1" has not yet been created. But it
> returns true. The function then returns the name "myfolder 2".
>
> If I immediately run the function again, it returns "myfolder 3". I can
> repeat that indefinitely, even though no folders have actually been created
> at all.
>
> To make sure I wasn't hallucinating, I used Terminal to run "ls -a" to view
> the directory contents. There were no numbered folders in the directory.
>
> I have no explanation, and it doesn't happen on my iMac.
>
> Part 2: Someone on Lion, using the same stack, has no problem with the
> folder check and gets a correctly-named folder to hold some created files.
> But when a handler later tries to access the files from that folder,
> LiveCode reports the files do not exist -- even though they are visible in
> Finder and the file path is correct. It feels like a related problem but I'm
> not sure how exactly. I can't repro this one.
>
> It's weird and I'm stuck.
>
> --
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
More information about the use-livecode
mailing list