unstable rawkeyDown

[dunbarx]

I have a stack that was just about my first. Made in HC over three decades ago and ported over to LC one decade ago. Just an address book that manages close friends and family, and most important, prints address labels for Christmas cards. Impersonal, but such a chore saver.

There is a rawkeyDown handler in the stack script that intercepts CMD-f, so that I can put up an ask dialog instead of invoking the standard LC "Find and Replace..." stack. Simple:

Code: Select all

on rawKeyDown tKey
  if the commandKey is down and tKey = 102 then --CMD-f
      ask "Find:" with the lastFound of this stack
      if the result = "cancel" then exit to top
      set the lastFound of this stack to it -- preload the same text, to find again
      find it 
   end if
end rawKeyDown

If I do not hold the "F" key for just a little extra while, the "Find and Replace..." stack opens. If I hold "F" for a half second, only the ask dialog opens. My "normal" holdDown time for "F" is just about on the cusp of what will invoke one or the other. If I consciously hold "F" for 10 more ticks than usual, no problem, I get the dialog.

The menu "Edit" hilites every time, so I know something is getting through. I just do not know what. Anyone know what I am talking about?

Craig

[FourthWorld]

What happens when you run the same test after first suspending the IDE?

[dunbarx]

Richard.

When you say "suspend the IDE", what does that mean? Suppress messages?

Craig

[bogs]

I think he means this -

I'm all in suspense over the outcome...

Apic_suspendIDE.png (18.25 KiB) Viewed 8943 times

[mwieder]

I'm all in suspense over the outcome...

groan

[dunbarx]

Me too.

What exactly, in that menu, where I suggested "suppress messages" lies, will "suppress" the IDE?

Craig

[bogs]

What exactly, in that menu, where I suggested "suppress messages" lies, will "suppress" the IDE?

Well, suspending the IDE will sure suppress it. You are the only one that mentioned suppressing messages, the picture was meant to answer the part of your previous post shown in BOLD below -

Richard.
When you say "suspend the IDE", what does that mean? Suppress messages?

The only way I know of to "suspend the IDE" is shown in that picture, where you "suspend development tools", which gives you about as close to a standalone as you can get while still in the IDE.

Again, Richard never mentioned suppressing messages, so I'm not sure how you got there from what he asked

[bogs]

I'm all in suspense over the outcome...

groan

Well, it was that or

[dunbarx]

Bogs. Richard

I have suspended development tools before. The tools palette, menubar and perhaps other things are hidden. Never saw the advantage.

But those do not affect the actual working of the IDE particularly, do they? All my library stacks and plug-ins still work, and all stacks work just as they always did. I just do not have access to tools. It never occurred to me that one described that state as "suspending" the IDE.

Suppressing messages, on the other hand, has a profound effect on the working of the IDE, and one can say that the IDE is, at least partially, "suspended".

So in what way might hiding my tools affect the length of time I need to hold down a key combination in order to attain a consistent result?

Craig

[FourthWorld]

Hiding the tools will also remove any frontscripts, backscripts, and libraries used by the IDE. Some of those contain keyboard traps, so worth trying.

[mwieder]

Craig-

You're tripping over your own code here.
If you hold down the key combination for a long enough time the keyboard repeat action is triggered.
That causes another rawKeyDown message in the stack.
...and when your rawKeyDown handler hits the 'ask' statement, there's already a modal dialog on the screen so it aborts and the rawKeyDown message gets passed along the message path to the next object that handles it. In this case the IDE's Find and Replace action.
And if you keep the key combination pressed you will continue to get more rawKeyDown messages passed to the Find and Replace stack - notice that it flashes at each repetition. But it's a singleton, so you don't get more than one copy.

Try this to see the repeats in action:

Code: Select all

on rawKeyDown tKey
  if the commandKey is down and tKey = 102 then --CMD-f
      put "rawKeyDown" & cr after msg
      if the result = "cancel" then exit to top
      set the lastFound of this stack to it -- preload the same text, to find again
      find it 
   end if
end rawKeyDown

...you might try adjusting your keyboard repeat rate to make it less sensitive.

[dunbarx]

@Hermann

Try this in the stack script:

Code: Select all

on commandKeyDown
   put ""
   put the keysDown
  end commandKeyDown

Press the commandKey, and then press "f", in the normal way. Do so again, and again. I get, randomly,
"102,65511" and "65511". So I cannot rely on that either.

@Mark.

I see what you are saying. But I have the reverse situation (mostly). A short press on the "f" key usually brings up the "Find and Replace.." stack, and now and then brings up the dialog. Only a deliberately longer press always brings up the dialog.

And yes, as you said, I just noticed that keeping the keys pressed brings up the IDE stack as well, behind the dialog. And it flashes nicely when holding those keys down.

Both the dialog and the stack are on screen. This is odd, no? First, how does a message get through an existing blocking gadget at all? Now then, with both on screen, I cannot dismiss the stack without first dismissing the dialog. This is not strange, because the dialog is blocking. But then how did the stack get a message at all to open the "find and Replace stack with a blocking dialog in front.... And round and round.

I am perplexed.

Craig

[mwieder]

The keyboard hardware/software generates rawKeyDown events. If it didn't you'd never be able to type anything into modal stacks like the ask dialog.
And the way the message path works is that the stack gets a chance to handle those events before the background libraries.
So the rawKeyDown message isn't actually getting through or around the modal dialog, you're intercepting it before the modal dialog has a chance to act on it.

[dunbarx]

Mark.

I see. OK.

But that still leaves me with an "unstable" procedure. I do not want the timing, finger strength or overzealousness of a user action to determine the direction of that action.

And that still leaves me, even with Hermann's offering, without being able to invoke the dialog reliably. I will try other methods and report back.

Craig

[FourthWorld]

Why use a rawKeyDown handler for something that can be handled well with a commandKey handler?