Thank to Peter, Dan, abachem and sleepy' contribution to this thread
I have the solution (aka hack) to make the hover work again seamlessly without manual intervention. I tested it and the hover is back.
The key action is what is what is mentioned by Peter and Dan. I didn't think initially this will work since when one click the custom prompt window, the window will be in the front which is exactly the same as what the action is doing, but anyway, since it is working so we proceed to step 2.
So the second part is how do we bring the hover back when window on focus.
This is the crucial code that works
Just add the following will make hover work again when custom prompt window get refocus
So assuming windowID of prompt window is saved into global variable kmImageTracker_windowId (you can create generic macro to accept passed windowID if you prefer)
the macro invoked is
Another alternative is using ProcessAppleScript provided we can use it to focus the window using applescript (this has advantage of not having a dedicated macro as a hack)
So will be good to try this solutions for those who has this issue.
This has been pestering me for past 1 year plus, finally at least there is workable solution
I will upload another macro to incorporate those changes soon for others to test.
That may not work, although it's worth a try. Peter said there were some issues using AppleScript and the engine from a prompt, and this sounds suspiciously like that kind of situation.
As for your solution, I'm glad it works for you, but I don't think it solves the problem I and others have been having. When it happens in my case, it won't stop happening until I restart the engine. It happens even if I just launch the prompt again. No switching to another app, nothing like that - mouseover events just quit happening.
I think sometimes it starts out intermittently, then after a short period of time it happens all the time, but I could be misremembering.
Thank macdevign_mac for your hack. Unfortunately, I have to agree with Dan. Using your 'hack' (as well as using my button-hack) helps (at least I think so), but does not solve the problem (at least not mine), since the 'getting back focus without hover-functionality' is a non-deterministic effect and in case it happens, it happens also if you bring (successfully) the window to the front.
Probably one has to understand the dependency (if there exist one at all) between 'bring a window to the front' and 'hover works', since as e.g. the Music.app shows, hover works also without the Music.app-window being at front and as our problem proves the other way is also true.
abachem, Dan,
I uploaded the macro for those who are interested. Actually after spending quite some time with it, I decide it is not worth my time to resolve it until a better solution from someone come along. It is a case of solving one problem while create another using the fix.
As you guy have mentioned, it is not a reliable solution.
I try to solve the hover issue foremost , and leave the "bring a window to the front' " for the rest to solve .
This is what I found on my system
ProcessAppleScript (didn't work) and windowId (seems to have timing issue)
The following macro uploaded works but has side effect (your system may exhibit different behavior though)
When KM Engine started, the first custom prompt window will able to show with hover working and when hovering on defocus-and-focus. But subsequent time, on showing custom prompt window again the hover may stop working, but hovering on defocus-and-focus works.
I putting the macro up for those who want to test in case someone in the future want to verify the behavior again.
I use this code to activate the custom prompt window by window title rather than windowId to avoid timing issue
tell application "Keyboard Maestro Engine"
set kmWindowText to getvariable "Local_kmWindowText" instance kmInst
set winlist to every window
repeat with win in winlist
set the_title to name of win
if the_title contains kmWindowText then
activate
end if
end repeat
end tell
thanks macdevign_mac for your Test Custom Prompt Hover Hack Macros. I have tested now various scenarios for a couple of hours and I am not sure that it really helps, because it is still unreliable as the solution without the hack and I could not create any scenario where I can reproduce the problem every time I call the chp. Thus I conclude that we have - so far - to live with the problem.
abachem,
my uploaded macro is for reference only, please don't spend too much time on this issue because from what I tested, I find that it is actually a focus issue that unlikely to solve by code or km action. The hover issue is actually a focus issue on the custom prompt window which when shown look like it is in focus (title bar no longer dim) but the html content area is not actually in "focus" hence the hover failed. I have also confirmed with textarea element, whereby the cursor does not shown and the element is not highlighted but yet text can be entered, only when I manually defocus the window and focus back again to the prompt window, then the cursor appear and text element highlighted (forced "focus" by applescript or actions will not work from what I tested). So it could also explain why hover didn't work (the html content didn't get 'focus' sometimes). This is the reason I didn't want to spend any more time with this as it apparently a bug in wkwebview or some other components that has to be fixed. All these issues are replicable on my system.
