Re: Script that "Tells" Finder just Focuses on Finder instead of running
Re: Script that "Tells" Finder just Focuses on Finder instead of running
- Subject: Re: Script that "Tells" Finder just Focuses on Finder instead of running
- From: Deivy Petrescu <email@hidden>
- Date: Mon, 05 Jan 2015 20:05:28 -0500
> On Jan 4, 2015, at 18:17 , Shane Stanley <email@hidden> wrote:
>
> On 5 Jan 2015, at 1:32 am, Deivy Petrescu <email@hidden> wrote:
>>
>> First, I said possibly because I don’t know the extend of the “search”.
>
> There's no real way of knowing that, as I see it. This is for a third party who is vision impaired, which presumably means he's likely to use it on *any* folder, and therefore it should try to cope with all possibilities.
Actually this makes the problem easier.
There should be a condition to stop the script from running (amok) on large folders.
If it is to display dialogs or say something, would the person really want to have over 1000 (being very modes) dialogs or spoken texts?
>
>> However, I can tell you that Phil’s solution provided me with a breakdown of my home folder faster than entire contents was able to cross one particular (“large”) folder.
>
> No question. But imagine the end user has his Applications folder open. He's going to be overwhelmed with information from a shell script. Or he has his home folder open -- entire contents is likely to time out.
Actually, as I said above, the script should not run if the folder in question has more than an acceptable but low number of files and folders.
>
> That said, the shell solution has the huge advantage of providing output in a usable format, and one that Alex likes. Suppose you know that the user will never use it on his Applications folder, and that entire contents will be fast enough. It seems to me that still leaves plenty of work to do converting a huge list of paths or whatever to a useful format. Doing the recursion in the Finder yourself would, I think, make the formatting part of the exercise easier.
Again, it would not work for the case in question, and actually I just found out that the ASObjC method you used is much faster than entire contents, which also I believe has a bug (see below).
>
> But maybe I'm missing something. So let's say you're using entire contents -- can you show some code for how you intend to take that list of aliases or paths and format it something like Alex suggested?
Actually looking at the output of theNSFileManager's subpathsAtPath:"/Users/shane" not just it was significantly faster than entire contents but the output is better to work with.
In any case, when I tried to run theNSFileManager's subpathsAtPath: “/Applications” it stalled ASE.
I haven’t yet tried "entire contents”.
Now for what I believe it is a bug
The original script posted
<script>
tell application "Finder"
set currentDir to (target of front window)
set CDir to currentDir as alias
set allFiles to (entire contents of CDir) as alias list
return (allFiles)
end tell
</script>
works fine. Now lets say that the target of the front window is my documents folder, this times out
<script>
tell application “Finder"
set allFiles to (entire contents of folder “HD:Users:deivy:Documents:”
end tell
</script>
Both pointing to the same folder.
>
> --
> Shane Stanley <email@hidden>
> <www.macosxautomation.com/applescript/apps/>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> AppleScript-Users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> Archives: http://lists.apple.com/archives/applescript-users
>
> This email sent to email@hidden
Deivy Petrescu
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden