TolikPylypchuk
Question: Windows application is working but the same application does not work on a mac
I have created a dotnet maui application with the idea to build a windows desktop and a mac desktop application. The development is done on windowI have excapsulated the sharphook in an EventHook class. In this class I create an SimpleGlobalHook and call the RunAsync() to start monitoring keyboard and mouse.
The EventHook class is added an an singleton via the AddSingleton<IEventHook, EventHook>(); function.
The first time the eventhook is instantiated is in the constructor of the App class. The SimpleGlobalHook is created, callbacks are set and the RunAsync() is called. then the keys and mouse usage is monitored.
this is working perfectly in windows but on a mac is does not work, no keypressed or mousemovements are detected. when i am debugging and checking if the correct functions are called i can see it is running on the main thread.
I am new to the mac, do you know if there is some extra work to be done to get it working on a mac or should it be sort of plug-and-play?
I have used the attached project to check. It is running on both windows and mac. But when I select the HookTest menu item in both platforms the window is displayed. But in windows when you press a mouseebutton the count increases and when you do the same on a mac the count does not change. MauiSharpHookBlazorTest.zip
Hi! Thanks for asking! I will look into and let you know what the issue may be.
Hello! Sorry to the delay, but I've just tried reproducing the issue, and on my machine everything works fine with the project that you've provided.
An important thing to remember that I didn't see mentioned here is that you must enable the accessibility API for an application for SharpHook to work correctly on macOS. In my case it had to be enabled for Rider since the app was a child process of Rider. When it wasn't enabled, the hook silently failed (the exception was ignored since RunAsync was not awaited). Maybe, the accessibility API was not enabled on your machine?
If you're sure that it really is enabled, then you can check what actually happens by placing a breakpoint inside the hook's RunAsync - right after this line:
var result = this.RunGlobalHook();
to see what the result is (e.g. if the accessibility API is not enable, the result will be AxApiDisabled. If the hook is actually started and is running, then you won't hit this breakpoint at all.
I have tried to find how to enable the accessibility API. I goto the apple on the top-left and select system settings. I select the Privacy & Security. I then can select Accessibility and add my application to the list and enable the feature. But then when I get to the call RunAsync I do get the Failed to start the global hook: ErrorAxApiDisabled (40)" message. What can I do wrong in the enabling of the accessability? There is also a "input Monitoring" selection, must I also add the application to this list?
This sounds right, but if you're starting the application from an IDE, then you need to give this permission to the IDE itself since the application is a child process of the IDE.
Regarding Input Monitoring, no, you don't need to enable it for SharpHook to work.
Could you please provide the debug logs from libuiohook? Maybe, we can find something interesting there. Other than that, I currently don't have any ideas as to why it doesn't work.
I have added the simple logging mentioned in the debug log page you link to. The code what is stated in section "Using High-Level Types" is added. I direct the logging to serilog. I get only my own logging but no libuihook logging at all. Either I am doing something wrong or the RunAsync does not run? I still am debugging and checking what is happening.
Could you please share the logging code? Maybe, there's some error there, because there should be at least some libuiohook logs. It would also be nice to try logging on Windows, to see what the difference is (since it works on Windows for you).
Shoot.... stupid mistake. I did the MessageLogged after the RunAsync call. Now I get logging on windows.
The code is:
and the logging is:
So it seems the eventhook is called and running on a windows machine but not running on a mac ?
Could you please also share the logs on Windows? This is really interesting, there should be at least something on macOS. Currently I don't have any ideas as to why this happens. Will try to investigate this a little later.
The windows logging is attached to this comment, it seems that the mac does not start detecting after the logline "hook event logging started"... hook-windows-logging.txt
Hi @R-Go-Tools, sorry for the long delay, but I've finally had time to tackle this issue again and was able to reproduce it. I believe this is not an issue with SharpHook itself as I was also able to reproduce it when using macOS APIs directly. I've opened an issue about this, and the solution described there worked for me:
In any case, I believe this to be a signing difference: all macOS apps are signed [1], but unless a signing identity has been specified or a provisioning profile is required, the app will be signed with a placeholder signature when building for debug. Using a placeholder signature has an important side effect when it comes to permissions: changing the app in any way (aka rebuilding it) will usually make macOS' permission system consider it a different app, thus existing permissions don't apply.
The fix is to sign using an actual signing identity, this can be done by adding this to your project file (you'll have to use your own value for CodesignKey):
<PropertyGroup Condition="'$(Configuration)' == 'Debug'"> <CodesignKey>Apple Development: J. Doe (XYZXYZXYZ)</CodesignKey> <EnableCodeSigning>True</EnableCodeSigning> </PropertyGroup>
And then rebuilding the app shouldn't reset the permissions.
Hopefully, this solution will also work for you, but in any case, I'm going to close this issue as this is not a problem with SharpHook itself.
Also, regarding the missing libuiohook logs on macOS - this is indeed a problem with SharpHook, and I've already fixed it. The fix will be included in the upcoming version 6.0.