I guess this is not new , but there is a way I can find some documentations about this ? I want to have same for our app on our website and when you press on it to open the app for example and do some things so I will need to know how do I doit on the website and how do I handle that in the OS as well on the app.
Does it work on Windows and Mac , or only on Mac , does it work on IOS ?
The new version of feedback will be a web application so this may be the better route for you to go with an online database, and the correct URL sent from your software all targets could access a web application to update/serve feedback requests.
These things are called URLHandlers. I have an IDE script to add those to my app (Mac only):
[code]'add url schemes
dim dbg as String
if debugBuild then dbg = â.debugâ
dim appNameForShell as string = PropertyValue(âApp.MacOSXAppNameâ) + dbg +".app" + â/Contents/Info.plistâ
appNameForShell = replaceall(appNameForShell, " ", "\ ")
dim BundleID as String = PropertyValue(âApp.Application Identifierâ)
if BundleID = ââ then
print âBundle ID for url scheme missingâ
Return
end if
dim theResult as String
theResult = DoShellCommand("/usr/libexec/PlistBuddy -c ââadd :CFBundleURLTypes arrayââ " + CurrentBuildLocation + â/â + appNameForShell)
Well it was not about feedback it was more about the App url itself, I will have it like myapp:// but I wanted to know how it will be implemented in Windows / Mac on the OS level so when you press on that web URL it will start automatically my app and handle the parameters.
[quote=467575:@Beatrix Willius]These things are called URLHandlers. I have an IDE script to add those to my app (Mac only):
[code]'add url schemes
dim dbg as String
if debugBuild then dbg = â.debugâ
dim appNameForShell as string = PropertyValue(âApp.MacOSXAppNameâ) + dbg +".app" + â/Contents/Info.plistâ
appNameForShell = replaceall(appNameForShell, " ", "\ ")
dim BundleID as String = PropertyValue(âApp.Application Identifierâ)
if BundleID = ââ then
print âBundle ID for url scheme missingâ
Return
end if
dim theResult as String
theResult = DoShellCommand("/usr/libexec/PlistBuddy -c ââadd :CFBundleURLTypes arrayââ " + CurrentBuildLocation + â/â + appNameForShell)
I assume that this is for the Mac side, is it doable for windows apps as well ? as I saw something here I guess some details about it but I will have to dig into it .
So apparently managing AppURIHandlers on Windows all the details are here , Iâll have to check as well how you do on Mac and then how you doit on the web side on a html site or php side as well , not only wojo web app.
Windows is tricky, because it will launch a second copy of your application with the url as the first parameter. So your goal would be to take that url and pass it to your already-running version, if there is a version already running.
My Beacon Xojo app does this for both Mac and Windows, though itâs much easier on Windows. I donât have a true tutorial available, but I can point you to some things to look at in the appâs code.
For Mac, as @Beatrix Willius mentioned, you need to update the Info.plist. In the Beacon project, there is an âUpdateInfoPlistâ build step that injects the url handler. There are a couple commands there, but you only need the one that adds CFBundleURLTypes. Next, youâll have App.HandleAppleEvent which just takes the passed url and hands it off to HandleURL which is where the cross-platform handling happens. Do what you want from there. So for Mac, this is pretty simple.
For Windows, start with the InnoSetup script in Installers/Windows/Setup.iss and the commands are down around line 104 at the time of this writing. You need to have your installer setup stuff in the registry to do it. Then back in the Xojo project, in App.Open I try to obtain a Mutex very early. If I cannot, that means an instance of the app is already running, so on Windows, I take the command line parameters and attempt to pass them to the other instance using an IPCSocket. If I can obtain the mutex, I open an IPCSocket and listen for the incoming parameters. This is the mHandoffSocket property with the event handlers mHandoffSocket_DataAvailable and mHandoffSocket_Error. The DataAvailable handler basically looks ahead of the buffer, and reads up until the Null character if the command is complete. When it is, passes off to HandleCommandLineData, which determines if it was a URL, and if so, hands it over to HandleURL again.
Thereâs a lot of work involved for Windows, which means plenty to get wrong. Sorry I donât have a real tutorial, but what youâre looking to do is definitely possible.
Trying to test this part, it seems that on MacOS is ok, but on Windows, it always launches the app each time the CustomURL is called, is there a way in case the app is opened to just pass the parameter and not to launch another instance of the app again ?
Any ideas on that ?
For the Registry part I put a code in the App.Open in order to check registry to see if the key is there or not and if not to create one, but it seems as well that I need the app to always run in Administrator mode in order to allow access to Registry, that could be a easy fix on editing the App properties but is there another way ? or Registry is only for Admins ? as access ?
You need to use some sort of mechanism to send the instruction to the already-running instance. A mutex and ipc socket combination is a common technique.
When your app launches, it attempts to obtain a lock on a mutex. If it works, it starts a listening ipc socket. If it does not, it connects to that ipc socket, sends the command line data, and terminates.
well the app is called from a browser URL so as far as I know to initiate an IPC socket you need both apps to know how to do that. For the 1 instance the mutex did the job , the parameter part is little bit confusing I guess. On MacOS we have the HandleAppleEvent that does the magic but nothing on windows so far .
I did found on the MSDN that apparently you need to Register the URL and then to properly handle it in the app, but Iâm not sure we can have that on XOJO. Here are the details https://docs.microsoft.com/en-us/windows/uwp/launch-resume/handle-uri-activation . I gues it would be nice to have similar functionality on Windows as well, that will open new horizons .
So, you mean that the GURL Apple Event works on MacOS and on Windows as well ? I guess then It has the wrong name for now I already handle that for the Mac side so if works on windows then I guess the issue would be only on registering the link and if you said that App Wrapper could do the job then Iâll have a look on it.