I have three Feedback cases that are all verified, they seem like things that really need fixing - and yet nothing has been done about them:
#998: IsWriteable fails on Network Storage Devices
#54984: SaveAsDialog won’t work on Mojave
#41649: Filetype sets can’t be copied, pasted, or exported
Even if nobody else has reported these problems, they sure look like important issues that just plain ought to be fixed. There is a workaround for #998, but it’s a silent bug that could bite any app, especially with the number of NAS devices being used these days. #54984 seems critical, doesn’t anyone use SaveAs anymore? And it seems really odd that there’s no way to move a Filetype set from one project to another.
I am very glad the engineers are promptly fixing beta bugs, but I’m still wondering why things like these aren’t dealt with.
[quote=456323:@Beatrix Willius]Because there are thousands more issues like that.
998: You try to write if it fails then you can’t write.
54984: seems a really special situation.
41649: that just causes us a minute or more work.[/quote]
Yes, I worked around 998 and that’s fine. If they’re not going to fix the problem, then they should remove .IsWriteable from the language, or at least add a big note in the documentation saying that it doesn’t always work.
#54984: My app has 9 different filetype sets, each set has between 3 and 7 kinds of files in it. That’s a considerable amount of work to recreate. Obviously, my app is unusually large, but pretty everything else in a project can be copied and pasted, and it doesn’t seem like it would be a tough feature to implement.
Don’t mind me, just venting, it’s been one of those days.
[quote=456375:@John McKernon]Yes, I worked around 998 and that’s fine. If they’re not going to fix the problem, then they should remove .IsWriteable from the language, or at least add a big note in the documentation saying that it doesn’t always work.
[/quote]
Its pretty much does
[quote]Even if IsWriteable is True, an attempt to write may fail for other reasons, such as coding errors or insufficient disk space for the information to be written. For example, a write may fail because disk space runs out midway through the write operation. IsWriteable is not intended to check for that condition. If your intention is to write to a file, you should simply attempt to do so.
[/quote]
I hadn’t thought of this one in a while. Write failure is one thing, but where I’m mostly bothered by this is in the fact that the IsWriteable flag is often false on a network volume when there is plenty of space and you do have proper permissions to do it even before you start any I/O. I see this on NFSv4 and CIFS volumes regularly from macOS and Linux enough that I now just write to temp file on the local volume and copy it over because I EXPECT it to be false regardless.
IsWriteable and IsReadable is complicated especially in windows. I came across the problem when I tried to save a project on a network drive and I fell down the rabbit hole which ended up in the feature being listed as unsupported in the IDE <https://xojo.com/issue/56325>. I have some test code in progress on this but its been on the back burner for a lot longer than I had hoped, I’ll get around to it one day.
Making the FileTypes external works fine. The icon doesn’t change though. I was able to import the xml into a new project where it overwrote the existing FileTypes. So copying sort of works with smaller bugs.
I don’t think isWritable on a network medium lack of reliability can be solely blamed on Xojo. At the end of the day, all it does is make available the system framework flag.
The quote from Raymond Chen on the Microsoft blog is quite right. Accessing the medium is the only way to know. And if it fails, you know. Beatrix was quite right.
FileTypes have been wonky for a looong time. Hopefully that will be fixed in the upcoming 2019R2, but as Beatrix rightfully notes, it does not take long to recreate one.