Exporting snapshots of objects.

[Brahmanathaswami]

Mac OS X 10.12.5 LC 8.1.8 rc2 (business)

result: nothing: no file output, result is empty, it is empty

[FourthWorld]

Mac OS X 10.12.5 LC 8.1.8 rc2 (business)

result: nothing: no file output, result is empty, it is empty

Does a file exist at the specified location?

[richmond62]

I suspect that LiveCode is exporting its snapshots inside the LC app as it seems to do on my Mac running 10.7.5.

Crack open the app and take a peek

This is "not very convenient".

[Klaus]

I think it is "not very clever" to NOT check the current defaultfolder in this situation if you have such a long experience with LC as you do!

[richmond62]

Klaus, the fact that I am "reasonably clever" (and we can have everlasting fun with quotation marks!)
was what made me have the "daft" idea of looking inside the LC app to see if, for some odd reason,
the defaultFolder was defaulting (ouch!) to there.

[Klaus]

I think that were more the hints on page 1 of this thread.

[richmond62]

to NOT check the current defaultfolder

I wonder what reason should make one assume that the defaultFolder has mysteriously changed from one version of LiveCode to the next?

[Klaus]

Maybe natural (or at least scientific) curiosity after not finding the screenshot where you had exspected it?

The "Applications" folder on OS X has always been "taboo", so you were just lucky with your older version of LC and/or MacOS 10.7.5.

[richmond62]

so you were just lucky with your older version of LC and/or MacOS 10.7.5.

Possibly . . .

HOWEVER, as I keep my LiveCode apps in a folder called "Livecode" (oh, well, you know . . .)
inside my 'Home' folder, rather than in my Applications folder, LC 7.1.4 was exporting
to that folder.

[FourthWorld]

I suspect that LiveCode is exporting its snapshots inside the LC app as it seems to do on my Mac running 10.7.5.

Crack open the app and take a peek

This is "not very convenient".

You're not alone with feeling that Apple's decision to try to tell users that a folder is a file is "not very convenient". Windows offers a single-file executable format that includes extensible multi-part containers, but apparently Apple feels consuming additional file system inodes is the better way to go.

But this is programming. Very little of programming is convenient. If we want true convenience we wait for someone else to write the program we want. It's supremely inconvenient to write one's own software.

[richmond62]

My

"not very convenient"

was actually a dig at the LiveCode people, to be honest.

I, too, do think the way Apple wrap their "things" up in disguised folders is a bit odd, but those who "go" with
Apple have to roll with it: and LiveCode has to roll with it, so they need to sort things out so that from 8.1.4 onwards the defaultFolder is NOT inside the LC app on a Macintosh computer.

As LiveCode got things right vis-a-vis the defaultFolder pre LC 8, I wonder what made things go wrong, and, even more interesting, why was I the first one to notice that something was wrong (or, at least, make a noise about it)?

[FourthWorld]

...but those who "go" with
Apple have to roll with it: and LiveCode has to roll with it, so they need to sort things out so that from 8.1.4 onwards the defaultFolder is NOT inside the LC app on a Macintosh computer.

Perhaps, but LiveCode is not an Apple-exclusive tool like HC and SC. And even among Apple OSes, Mac OS (v9 and earlier) used a single-file executable format, while macOS (v10+) uses the bundle format. Should they special-case Apple from everything else, including older versions of Apple OSes? How many LC devs rely on the consistency? Is that number smaller than the number who use the defaultFolder without ever changing it?

...why was I the first one to notice that something was wrong (or, at least, make a noise about it)?

Most people install applications in the Applications folder, so the defaultFolder is never writable by user processes with or without Apple's bundle format.

Others understand that global properties like the default folder can be set and changed by any component at any time, and account for that at least once in their code by explicitly setting it to a specific desired value, something commonly user-writable like Documents, Desktop, etc.

Your experience here seems to occupy an uncommon intersection of interests. Not unreasonable for your own needs and way of working perhaps, just apparently uncommon enough that this hasn't come up often before.

Keep in mind that while the default folder may "normally" be the location of the exe, that's not always the case. Some OS preferences and/or OS extensions may set the working directory for a process to any path when the process is launched.

For this reason the Dictionary entry includes this note in the entry for "default folder":

The defaultFolder is a string consisting of a valid path to a folder. When a LiveCode application starts up, the defaultFolder initially contains whatever the working directory was at the time the application was launched. Typically this is the folder that the application resides in, however this is not always the case and shouldn't be relied on. It is best always to set the defaultFolder before using relative paths.

Personally, I usually avoid the ambiguity of relative paths like the plague, preferring to make sure each path I use is explicit wherever practical.

[Klaus]

Please also check my bug report concerning the "defaultfolder" in different LC versions:
http://quality.livecode.com/show_bug.cgi?id=19140

[FourthWorld]

Please also check my bug report concerning the "defaultfolder" in different LC versions:
http://quality.livecode.com/show_bug.cgi?id=19140

Peter Brett's comment #3 in the linked duplicate seems to describe the situation well:
http://quality.livecode.com/show_bug.cgi?id=18008#c3

When updating to newer APIs, we can expect improved (more OS-conformant) behavior, even where it may differ from older versions using deprecated APIs.

On Windows we learned long ago not to rely on the default value of "default folder" because there's a Properties setting for apps which lets the user explicitly set that to any folder.

Even on macOS, per PB's comment, modern APIs allow for system and extension components to use a value other than the app. Almost anything other than the app makes sense, really, since the active directory for a process will often determine the initial location for file pickers like Save As, and Save As will not be possible in a properly-installed app within the Applications folder.

Explicitly defined paths are the safe way forward. Relative paths can sometimes be useful, but are predictable only when you've first explicitly set the default folder within your own code.

[jacque]

I wonder what made things go wrong, and, even more interesting, why was I the first one to notice that something was wrong (or, at least, make a noise about it)?

Maybe because few people rely on it. Like Richard, I almost never use the defaultfolder. It's not only apt to change, but in standalones the startup default directory is unwritable on most operating systems. SpecialFolderPath is more useful in general.