Hello,
In my app, while a process which can take from a fraction of second to almost 2 minutes (depending user’s choices), I use NSEvent’s modifierFlags() in the loop to catch the Cmd+ Crtl keydown to cancel the action.
Well, BUT, even when I give the focus to another app, mine catches the modifiersKey strokes and react unexpectedly.
I searched a while how to fix this behaviour, but was incapable to manage it 
Any help, please ?
With regards
Joseph
(Xcode 4.6.3 with Lion 10.7.5 on MacPro)
Ok, I used this very Applescript way to manage my request :
repeat
-- in the curse of the loop
set modifierNumber to current application's NSEvent's modifierFlags()
if modifierNumber = 1310720 then -- CmdKey + Ctrl keydown = to cancel operation
tell application "System Events" to set frontApp to name of first process where frontmost is true
if frontApp = myAppName then -- the var contains the actual name of this application
display alert "User cancelled the process!" buttons {"OK"} default button 1
return "Canceled" -- this result returned to its parent handler triggers the actual cancelling process
end if
end if
-- the rest of the loop handler following
Probably exists a more “Cocoa” way, but this does the trick.
Joseph
Model: MacPro
Browser: Safari 537.78.2
Operating System: Mac OS X (10.7)
Rather than a tight loop, you might be better to use a timer that runs every 0.x seconds. And you can use something like this:
if (current application's NSApp's isActive()) as boolean then
Hello Shane,
Certainly less consuming proc resource into the loop!
I’m just puzzled about how to manage it, but I’ll try.
Must I insert this timer in a <on idle / end idle> handler?
Thank you for the advice.
Best regards
Joseph
Model: MacPro & Xcode 4.6.3
Browser: Safari 537.78.2
Operating System: Mac OS X (10.7)
No – you just trigger it when your process starts, and invalidate it when it finishes.
Hello Shane,
With help of your «AppleScriptObjC Explored» (definitely the must-have book to jump into Xcode from vanilla AppleScripting) I could figure out how it worked.
Naively I expected that a Timer could behave as background temporiser which could insert his action at intervals through a running loop. Well, it’s the loop or the timer, not them together.
So my code needs some rearrangement to pass from one way to the other, but it’s not too complicated.
My question is about the timing when choosing a timer to behave like a loop. Because it seems quite unpredictable to me.
Let’s figure I put 0.001 sec as delay and the process that the timer must manage takes eventually 0.025 sec and will be triggered hundreds of times?
What will happen? Any risk of CPU or memory overflowed?
You’ll probably flood the event queue, resulting in a spinning cursor and worse.
You should rarely need to check anything that often – checking for a key-press is something for which 0.1 seconds is probably more than adequate. But if you have a situation where you are worried about timers firing before a triggered handler is finished, the best approach is not to use a repeating timer. Instead, just create a new single-shot timer at the end of the handler each time it’s finished its work.
OK, I agree that my example was voluntarily exaggerated, but better be aware of possible issues when trying to speed-up artificially the process.