LiveCode Forums

One of the ways round this problem is to search for all the "things" lying around one's
Mac desktop (or elsewhere) and separate them into 2 fields: one for "things" that have suffixes, and one
for "things" that don't; then run a second routine to move all the "things" in the have-suffixes field into
a third field; and then what you have left are files-that-are-really-folders.

Guess I'll have to fire up my osx'en vm, I figured if you had a file that wasn't being listed, it would show up as a folder in the previous code, and you would then *know* it is one of these mac things like you were discussing above.

Mac and Windows both hide file name extensions by default.

And GaragaBand folders have an extension.

Maybe simpler to try "is a folder".

Ok, I'm lost, want to elaborate?

Here is what I was thinking about his initial post -

Curious about this and think I'd learn something if I had the answer.
.jpg, .mp3, .pages, .doc ETC. all work in this script but .band files don't.

So, you have something that *looks* like a file, but doesn't list in 'the files' function (where he was pulling tFiles from).

My thinking was if you saw something like that, you would drop that folder into the path and separate out both folders and files, if you see the name of what your trying to look at in "folders" section, it tips you off so to speak that it is not going to be a file.

This is the test I'd run if something doesn't act like what it appears to be, not if I know ahead of time what it is (folder or file), like what our friend asked at the beginning.

To throw another wrench at the monkeys, there's also the issue of aliases, or links, or whatever your favorite operating system calls them.

To differentiate between actual files and aliases to files you can use the aliasReference() function:

local xFiles
-- set the defaultFolder to the folder you're interested in
put the files into xFiles
repeat for each line tFile in xFiles
put aliasReference(tFile) into xFile
if xFile is empty then
-- use tFile
else
-- use the linked file instead
end if
end repeat

mwieder wrote: ↑

Sun Feb 25, 2018 2:27 am

To throw another wrench at the monkeys

I'd like to see you try it !


Seriously, though, the code is neat. I hadn't hit that problem myself yet, but I'm sure that now that you've put that there, I will hit it just as soon as I've almost forgotten where I saw this

I actually use a variation on that to allow widgets to be stored in any location, not just in the Extensions folder. And with a little more sleight of hand it's cross-platform if you identify how Windows, OSX and linux store aliases.

I know this is a month old but...

I think someone already mentioned Answer Folder is how you select a bundled file format (like .app, .pkg sometimes, .rtfd, .band )
EDIT: I just tested and was able to select a .band bundle file from 'answer file'

The reason these types of bundled formats exists is because it allows for resources associated with a Thing (like icons used in a .app) to be neatly packaged together with a Thing so that when you move Thing somewhere else, all of the associated resources / dependencies are move along with a Thing. This comes from Mac OS X's NEXTStep heritage and is similar to the way "Classic" Mac OS 9 and earlier would bundle resources in a special part of the file called a resource fork (along with a normal data fork that all operating systems have), this is specific to the Mac OS file system HFS/+.

Anyway if you are trying to open a GarageBand .band file bundle in LiveCode just for playback, well you can't, only GarageBand and LogicPro can. BUT, you can go into the bundle and look for any resources used inside the .band composition (folders), such as .wav .aif .mp3 and .caf files. A CAF file is a CoreAudioFormat file and it usually contains some MIDI header data with info like tempo/time signature and also, but not always, Musical Note data. I actually wrote some (rough) LiveCode scripts for converting MIDI data embedded in .CAF format loop files into normal MIDI .smf /.mid files.

BTW, IMO bundles are an extremely useful way to store things (Richard), I can edit the audio recordings used inside my .band files in an audio editor and then when I open the .band bundle in GarageBand again all those resources are updated. I don't have to worry that I linked to the wrong edited file or forget to copy it to my archives along with the composition that it goes with because it's "inside" the composition (bundle).

For what it's worth, I miss resource forks, but bundle's are the next best thing and they're compatible with non-Mac HFS file systems.

I miss resource forks

I can't say I do.

I guess they could be a PIA, there were some benefits, like it was great for quickly scanning through large high-res images/Illustrator Files/Photoshop etc. that kept low res previews and thumbnails in their resource forks, back then displaying a poster size image could choke your system to a halt.

BTW, I just tested in LC 9.0 on Yosemite (10.10.5) and I had no trouble at all selecting a .band file from this script: