Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Event Processing Basic Query...
Message
From
04/07/1999 11:38:04
 
 
To
03/07/1999 11:25:13
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00236220
Message ID:
00237327
Views:
8
[From: Dragan Nedeljkovic To: Harry Stottle]

>>Or can you create an invisible but active form just full of "hotkey buttons" appropriately defined >>>which could part of each relevant formset...

>
Several things ahead: you may rewrite your hotkey definitions to get into the form class definition, in the KeyPress - that way you're safer from the, ahem, "possible future funkiness", and your hotkeys which are defined to work on a form will work only while that form is active. If it weren't so, you could bring up another form, or a report preview, whatever, while your form is running, and your OKLs would still apply.
>

noted but like I'm asking of Jim, are you saying this method is superior to the menu method?

>
Another potentially dangerous which burned my fingers with OKLs was Pentix. It was a Tetris clone, played by several guys, who usually stuffed keyboard repeat accelerators as TSRs, so I'd get full keyboard buffer of keypresses if I didn't release the key immediately. Now if it was a key with an OKL definition, a funny thing occured - the OKL was called for the first keypress, then it was called again for the next one, before any lines of its first instance were executed. It actually did nothing, but put an enormous amount of calls on the callstack, which usually broke up with "Do nesting too deep". I've tried several things, like Clear Typeahead, Set Typeahead to 0 etc as the first command in my OKLs, but they never got executed - the keyboard buffer took precedence, i.e. an OKL call interrupted execution of the same OKL call before it's first line.

Now this was happening in DOS days, and I've not checked this in VFP, simply because I don't use OKLs anymore (maybe sometimes, during a browse - and scoped to that browse only - but not in production, only in some of my tools). The keyboard settings, however, are done at Windows or BIOS level now, so you can't control it. Do a test: define an OKL, and keep its key pressed. See what happens.
>

yes - in DOS, holding the key does upset the OKL routine.
>


Another thing: I've done a "redefine all keys" routine once, back in FP2.0 - and it was dead slow, took more than two seconds to execute. It may be fast enough now, but - why should it run in the first place? Use KeyPress, it runs only when it has to. If your keys are mostly Fx keys, you can cut short through the long Case in KeyPress, like this:

case nKeyCode<0 && a-ha! an F key
do case
case nKeyCode=-1 && F2
...
endcase
case nKeyCode=whatever etc etc
otherwise
DoDefault(nKeyCode, nShiftAltCtrl)
endc
>

I'll file that in my 'Possibly useful keyboard tricks' folder!

>
Pair this with the other message. I hope I didn't ruin your week.
>

not so far, but we've got a new one starting! :-)


Harry
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform