Trying to send doc feedback I click here on the new site:
Have a suggestion about the docs? [Let us know.](mailto: docs@xojo.com)
Safari reacts by giving me guff about the classic environment and saying it can’t handle mailto: which is nonsense.
I do notice a space after the colon (:) in the mailto:, is this the reason? Seems to affect the old doc site too.
No problems here with Chrome or Safari, macOS Mojave/Catalina.
The link opens Mail correctly.
Just putting mailto: and an email address doesn’t make a link on a website. At least on the average browser. The mailto:email@address.com has to go in a link. That said a lot of browsers (Safari especially) will spot an email and make a link automatically.
Tim is talking about the link that Xojo has on their documentation page, usually you see them without space. I don’t know if that is causing the problem. Here is the code:
I wonder if removing that space will fix Tim’s problem.
No. I just made a tiny test page with a correct <a> link as @AlbertoD describes. Using Mail, I can set my email client to be the default app for mail, and clicking the link in my test page then fires up my app, but the wrong copy of it. Since I’m the developer of my email client I have a number of copies floating about, and even though in Mail I navigate to the copy in /Applications, the wrong copy, probably an ARM version, is picked to be launched by Safari. I expect its drivel about the Classic environment is probably an old message from 68k days and Classic macOS. If I try Firefox then it launches a different wrong copy.
So it’s prolly nothing to do with the docs page after all. This is very frustrating as we’re going away for the w/e for a birthday do it’ll have to wait until Monday, now. My suspicion is that although I have a mailtoRegistrationScript for my app that uses PlistBuddy to register my app as able to handle mailto:, this may be being undone when I run the app through AppWrapper. There’s a section there about URL schemes which is empty. Perhaps I need to put something in there.
@Sam_Rowlands is this the case and what do I need to put there for mailto: ?
IIRC App Wrapper does not replace the URL handlers unless URL handlers are specified within App Wrapper. I will attempt to verify this at some point today. Mind you, if it did and you wrapped all the copies of your application, none of them would launch.
My honest gut feeling is that you need to reboot to rebuild the launch services database. This is sadly another area that Apple have neglected over the years and often gets corrupted/confused and just downright broken.
There are even declares in the Ohanaware App Kit that you can use to check to see which application the macOS has associated with the mailto: URL. If needs be, I can take a look and see if this is possible to also manually set this association (like Safari asks to do when you accidentally launch it).
Thanks Sam. I’ll check out the reboot on Monday. I’ll mark this as solved, meanwhile.
Turns out that my post-build script to modify plist.info for the app to add mailto as a URL it handles, was silently failing. I fixed this and improved the script and that is working as intended. However, it looks like AppWrapper does remove URL handling if nothing is specified in the URL Schemes part of the General pane. I think I would argue that merge rather than replace would be preferable here.
Out of curiosity, why do you use a post build script? Does dragging a Info.plist into the project not work for URL handlers?
Probably through ignorance when this was set up. I must have obtained the post-build script from someone but didn’t think to make it robust. It worked though. Today’s problem seemed to be that either the meaning of CurrentBuildAppName got changed to include the extension, or I changed that in whatever IDE spot it’s set.
And I do have an info.plist, probably as a result of advice, containing:
<dict>
<key>NSAppleEventsUsageDescription</key>
<string>You will be allowing the app to respond to mailto: links</string>
</dict>
<dict>
<key>NSApplicationCrashOnExceptions</key><true/>
</dict>
and while fiddling with the script I was minded to wonder whether I should just take the output it generates and stick it straight into the plist. That ought to work. But there’s still AppWrapper too.
Yes. From Release Notes for 2022r1:
The CurrentBuildAppName build automation script constant now includes the full app name, including extension, for macOS desktop apps when doing either a debug run or a build.
Thanks. The lesson is, always check error codes unless you really don’t care about whwther something fails or not.
OAK.initWithArguments( kLaunchArgumentCrashOnNSException : true )Building my app gives this (amongst other items) in the info.plist file inside the Contents folder, added by the post-build script:
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>CFBundleURLName</key>
<string>MailTo</string>
<key>CFBundleURLSchemes</key>
<array>
<string>mailto</string>
</array>
</dict>
</array>
If I then wrap the app AW 4.4.1 (217) and with the URL Schemes section empty, the wrapped copy’s info.plist contains:
<key>CFBundleURLTypes</key>
<array/>
which seems to agree with the Information Property List (looking at the XML).
I’m quite happy to remove the post-build script and let AW do the work for the URL scheme.
Tim,
Thank you for taking your time to help me understand this issue. I’ve been unable to reproduce it here, but i think I have an idea of what may be the cause.
Is it possible that with either version 3 or version 4 of App Wrapper, you once used it to add URL types to your application and then removed them? I will test this theory today, but I do suspect that either v4 or v3 wasn’t removing the dictionary after it had emptied it.
Looking at the code for the helper (the bit that does the processing), it does do a merge, however that’s of the main branch and dictionary leaves. I would have to write a dedicated merge system for each kind of array leaves as there no way I can do it once for all. Basically the helper needs to know what to expect in the array in order to test to see if a matching element already exists.
In the meantime, if you select “Information Property List…” from the “Edit” menu and click on the remove icon next to CFBundleURLTypes this should solve the problem for you.
Thanks for your help and sorry for this problem.
Addendum as I seem unable to Edit that previous post. In the plist editor, you have to right lick and select “Remove”.
I must apologize as I have now recreated the issue, I felt sure I remove the array if you remove the last entry, but I don’t (at least in this case). I will change that and I am drawing up different ideas on how to handle empty arrays at wrap time.
Hi Sam,
I can understand that doing a “proper” merge (whatever that may mean, exactly) could require some effort in code and also likely some arbitrary decisions when there are conflicts. I wouldn’t be looking at AW as a full-featured plist editor - perhaps some simple rules would suffice like (a) if this AW section is empty then the corresponding plist section is left untouched, (b) if there’s anything at all in this AW section then the corresponding plist section is replaced in its entirety. As long as that’s made clear then there’d be no surprises. However, that’s just my uninformed suggestion, so I won’t comment further there.
Meanwhile I removed the post-build script and added the URL Schemes entry in AW and that is fine. I do have a plist file added into my Xojo project, it has the two entries I mentioned before for NSAppleEventsUsageDescription and NSApplicationCrashOnExceptions - can those be incorporated via AW?
Also happy to help testing if that’s useful.