Has anyone experienced this behaviour in OI before.

We have developed several OI forms where Shift+F9 or Alt+F8 does a specific function. However, if the key combination is not struck "deliberately", for lack of a beter word, the F9 or F8 occurs instead.

The normal key processing happens just fine in Arev using the same key sequence and computer.

Thanks in advance.

John,

Has anyone experienced this behaviour in OI before. We have developed several OI forms where Shift+F9 or Alt+F8 does a specific function. However, if the key combination is not struck "deliberately", for lack of a beter word, the F9 or F8 occurs instead. The normal key processing happens just fine in Arev using the same key sequence and computer.

I've never had a form with Shift'ed accelerator keys before, but decided to try it now since it's likely I will need this feature in the near future. So I tried a very simple form here with Shift-F9 and everything works ok. I can press the Shift key any way I want. My OI is version 3.61.

Do you do any key handling yourself in your app? Any advanced event handling? Anything that keeps your app very busy? (I'm on thin ice here.)

I know of a case where the Shift key isn't always recognized. But that is with Windows Explorer and not an OI app. In Explorer one can supposedly delete files permanently with Shift-Del, i.e, they don't go to the Recycle Bin. (One still gets an agree dialog, but a different one.) I say supposedly because very often the Shift keystroke isn't recognized. This case may be something altogether different from yours. With Explorer I don't think it helps to press the Shift key "deliberately" either. (If anybody reading this have a remedy for the problem I'd be glad to hear about it.)

A different case I guess all of us sometimes have experienced is "stuck" Shift, Ctrl or Alt keys. They're not physically stuck; it's like their state have become programmatically inverted. If the Shift key has become "stuck", it's similar to when Caps Lock is on, except Caps Lock works for the letter keys only. Pressing the "A" key by itself produces an uppercase "A" instead of a lowercase "a". Pressing Shift-A produces a lowercase "a" instead of an uppercase "A". To "release" the "stuck" key you must press the key (e.g Shift) alone. The reason this problem appears must be a bug somewhere - either in Windows or some application. I don't believe you've managed to make such a bug in your app, but at least you can check if it makes any difference if you tap the Shift key once before you press Shift-F9.

A third case is worn-out keys, but then the problem wouldn't be confined to function keys and OI apps.

Probably not much help in this.

- Oystein -

Thanks for the response.

On the screen in question there are 14 different shifted and alt Accelerator Keys. This app was ported from AREV and we tried to keep the keyboard functionality as close to the original app as is possible. There is also quite a bit of event handling occuring behind the scenes. Mostly reading/writing logic or LostFocus.

Anyway, I will experiment with creating a small window with one shift key and see if I can reproduce this behaviour.

It seems as though the timing of how fast the keys are pressed in succession is what if failing.

Thanks again,

John Bouley

John,

Not much to thank me for.

One naive idea I had was: What if your app is busy with something when the Shift key is pressed, but finished with that business the split second later when the function key (e.g F9) is pressed. So the Shift is lost and only F9 is recognized. - But OI apps don't work that way. The keystrokes are nicely queued. (I even tried BLOCK_EVENT, but couldn't manage to lose just Shift.)

Next naive idea about how the problem might occur: Have a CHAR handler that forwards the CHAR event without all the parameters, or with the parameters set to 0. - But no. Too late.

Final naive idea: Perhaps my silly ramblings will provoke somebody more competent to respond.

- Oystein -

Well I tried my test and created a simple unbound form.

The form has a menu with a quick event tied to Shift F1.

It appears that the Shift F1 works if you deliberately hold down the Shift and then press the F1.

Unfortunately I tend to type quicker (and my customer too) than OI seems to recongise the Shift Key. If I quickly hold down the Shift key and press the F1 with the same hand it appears to have a threshold where it will not work.

Interesting, when testing the Form (Cntrl-W) I use the same speed and it works every time but with Shift-F1 (or another accellerator key) there is a difference in the sensitivity! Just an observation, but I would be interested in knowing if anyone else can reproduce this?

Thanks in advance,

John Bouley

John,

Interesting, when testing the Form (Cntrl-W) I use the same speed and it works every time but with Shift-F1 (or another accellerator key) there is a difference in the sensitivity! Just an observation, but I would be interested in knowing if anyone else can reproduce this?

Both yes and no.

I made a table-bound form, with default menus. So F9 was the accelerator key for saving a row. Then I added an extra menu item with an accelerator key Shift-F9, with a quickevent to bring up a simple message box. Then I tested both Ctrl-W (Test Run) in Form Designer, and Shift-F9 on the running form.

Ctrl followed very closely by W consistently worked fine, but with Shift-F9 the results seemed to vary with what went before. Here are the details about Shift-F9:

If Shift-F9 was successful the message box appeared. Then I clicked the OK button and immediately repeated the experiment. Let's call this case A, i.e, doing the experiment after having clicked the OK button of the message box.

If Shift-F9 failed I got F9 instead, i.e Save Row. Since I used the default settings my form cleared. Then I filled in the form with a new row and immediately repeated the experiment. Let's call this case B, i.e, doing the experiment after having filled in the form with data for a new row.

In case A I could follow Shift very closely by F9. It even seemed I could press F9 a split second before Shift, and it still worked!

In case B I could follow Shift rather closely by F9, but not too closely.

But it wasn't exactly a scientific experiment. With those quick finger movements it's difficult to know precisely what you (I) do.

- Oystein -

Many Thanks,

At the very least you have set my mind at ease that I am not going crazy! I know it sounds picky but the users of this app are used to using these "Accelerator Keys" and if they don't work the same as AREV it can be a problem.

Our company is a member of Works, I will place a support call to report this "behaviour" and see where it goes from there.

Thanks for your help,

John Bouley

John,

At the very least you have set my mind at ease that I am not going crazy!

What about me then? Was I crazy when I saw it work when I pressed Shift after F9?

Our company is a member of Works, I will place a support call to report this "behaviour" and see where it goes from there.

I doubt that you'll get any useful response.

Your best bet might be to put stiffer springs beneath your (users') function keys.

- Oystein -

Maybee you have a Kyslexic Deyboard?

Anyway, Thank you very much for your responses.

John,

Perhaps my keyboard is what your clients need? Any offers?

- Oystein -

Depending on the timing, the code might be getting sent to the wrong window, if other processes are happening…

The Sprezzatura Group

World Leaders in all things RevSoft

Sometimes it's the simplest things so…have you tried a new keyboard?

The Sprezzatura Group

World Leaders in all things RevSoft

I've tried a different computer and OS it still works the same

Sprezz,

Do you mean the Shift keystroke could have gone to another window? And F9 alone to the intended window? Is that at all possible?

- Oystein -

We've seen stranger things..

The Sprezzatura Group

World Leaders in all things RevSoft

Do you know that in MS Word holding the Shift key halfway down while pressing PgUp/PgDn makes it scroll just half a screen?

- Oystein -

View this thread on the forum...