I have been modifying ARGEN to get rid of the MBS dependencies (as I don’t have it) and to be able to compile it for API 1 on 2019r1.1
Tim had the Help use a mac specific mechanism to show the help, for windows he just Launched an Index.html file that was in the resource folder…
OK I though that should work on a Mac too so I commented out the Mac specific stuff and ran it on 2021r1.1…
Well FolderItem.Launch failed silently and when I changed to FolderItem.Open I got an exception… But I checked in the debugger and the file existed and all looked OK…
OK I though must be some sort of Mac security thing… and took the next steps to convert to API 1.
After I converted the Vars to DIMs, DateTimes to Date, and SearchFields to TextFields then ran on 2019r1.1, when I selected the help menu item FolderItem.Launch worked as expected on the index.html file!
As this is on the same machine running 10.14.6, obviously this is not a Mac OS issue (at least in Mojave), but a change in Xojo…
Did I just stumble over a bug in 2021r1.1 that affects both API 1 and API 2 or is that an expected behavior for some reason?
What was the exception text or code with the .open method?
The application “index.html” could not be launched because a miscellaneous error occurred (OSStatus -36).
-36: Input/Output error
(looks like a weird and unexpected error in this context)
If you copy the NativePath from the IDE and paste it in a Terminal window, does it work?
Do you have an application selected to open HTML files?
The MBS stuff was specifically to find out what your browser was so that HTML opens in the browser for developers like me with HTML files set to open in an editor.
Never changed it from system defaults…
Given that it opened with Safari when I used 2019r1.1 int should have in 2020r1,1, no?
That sounds like a default application to me! Was just a guess as I’d never encountered that code before.
No such file or directory
It seems to be specific to that index.html file. Even if I move it to my desktop and grab it from there, it gives me the error. But other html files work just fine.
Edit: If I copy the contents from that index.html file into a new one and copy it into the HelpBook folder, things work fine. Something is goofy with the file for sure.
Edit edit: Also, if I “chmod -x index.html” on the original file it works fine. But “chmod +x” doesn’t break it again. I don’t understand enough to go further but maybe someone else can figure it out.
One other thing - I don’t get the error using the released version of 2021r1.1. Both fail silently until I do the chmod -x bit.
Weird…That file was in the ARGEN GitHub download and that one is actually a copy… I copied teh folder out of the ARGN project and pasted a copy into a new folder for the simple example project.
But if it is the file, why is there no issue in 2019R1.1? Also if I double click on the file in finder it launches just fine… It’s ONLY on Launch (or open) in 2021R1.1 that I see an issue.
That is what I tried it on!
I agree, it’s weird. It opens for me correctly as well, and validates just fine using some online checkers. But until the chmod thing Xojo 2021r1.1 won’t open it. I’m sure it’s not actually the chmod -x that’s fixing it, but something else must be getting “fixed” when you do that.
In any case this means something under the hood has changed with Xojo FolderItem.Launch/open under the hood since 2019R1.1, and it’s not positive if other apps don’t have an issue.
It’s not the first time I can’t open files from Feedback:
I made a super weird Feedback case with a Filemaker file that makes an IOException when using .Open but not for .Launch: <https://xojo.com/issue/64682>
This means the OS accepts to open the file if it loses its execute attribute.
The difference of behaviour between Launch and Open probably mean another API is called.
It could be the OS denying to open an HTML, executable, file (for “security” reasons) with the newer API…
This is similar as when you download an executable file/dmg and it runs in translocation; next, if you move it to another folder, the translocation mode is removed and you can even put the file back to its original location.
But that’s perhaps a coincidence.