Problem with KEYBOARD command

[Brak]

I have created a keyboard trap. I have all the keys associated with ON KEY LABELs. I have a function called by the ON KEY LABELS which issues a KEYBOARD commands so that the key caught by the ON KEY LABEL is placed back into the buffer.

When I am in a @GET, the letter is always placed in the front, even if I place the cursor in the middle of a word that is in the @GET.

For example:
The @GET field says:
Brak is cnfused.

I place the cursor between the 'c' and the 'n' and press the 'o' and the result is:
oBrak is cnfused.

Thanks in advance.

B"H
Brak

 

[DSummZZZ]

What is the OKL for 'o'? Is there anything besides
KEYBOARD 'o' ?
Am I understanding correctly?


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Brak]

This is an example:

In the setup of the program I have:
ON KEY LABEL "o" m=proc()


In the cleanup of the program I have:
func proc
keyboard "o" plain
***various other code***
return .T.


Now when I type in "o" it is placed at the front of the @get. Causing the situation mentioned in my original post.

Thanks.

B"H
Brak

 

[DSummZZZ]

I tried your example. I don't know exactly why it does what it does, other than when an OKL happens, program execution goes to the called routine (proc()) then returns to the GET. I'm sure Fox just re'reads' the GET from the beginning. Even if you define for instance, an OKL for F12 as KEYBOARD "o" PLAIN, put the cursor where you want it and press the key, it acts the same way. I think you're going to have to rethink your keyboard trapping.


-Dave S.-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Brak]

Annoying isn't it? I have spent days trying to figure it out, but to no avail.

If FP would work right with this, it would open for many solutions. For example:

Password entry:
Func can place "*" into the get but store the actual keyboard presses.

Right to Left entry:
Func can add a LEFT ARROW for each keypress causing the entry to go Right to Left (This one in the main motavation to get this to work).

So what can I do with the @get to keep FP from restarting the @get?

Thanks.

B"H
Brak

 

[ghunaima]

Try method used in following procedure instead

on key labe "o" m = proc()
x = 'Brak is cnfused'
@ 5,1 get x
read

func proc
c = col()
x = stuff(x, c, 0, 'o')
return

 

[Brak]

Sadly it doesn't work.

It almost did, but not quite.

When I place the cursor in the middle of a word and start typing, first my first type is ignored, then cursor apears at the begining of the @get, but the next letters I type apear in the middle of the word like I want it to, but the cursor is still in the front of the @get.

Also, a few times the letter appeared far down the @get, for example:

Original: Brak is cued
Result: Brak is cued onfu

But sometimes it does work, but the cursor is at the begining of the @get and the first letter typed is ignored.

Thanks for the help so far, this is definantly going down the right path.

B"H
Brak

 

[Brak]

Ok, this is weird.

I decided to just make a temp prg with the exact code you gave. And I noticed something interesting.

In the line Brak is cnfused:

If I click anywhere before the word 'is' the cursor gets placed at the begining of the @get, but if I click anywhere before the word 'is' then the code works perfectly.

One time after I clicked after the word 'Brak' I started to click at other places and it was working perfectly.

This is truely weird.
So what would cause it to behave goofy at times, and what can be done to pervent it.

B"H
Brak

 

[Brak]

Ok, things are semi-cleared up. I realized that when it wasn't working I was pressing 'o', and when it was working I was pressing a key other than 'o'.

So this means that your code is doing the same thing the other code was, sending the cursor to the begining. The only difference is that the text is going into the right place (except for first key being ignored), but not the cursor.

What can be done?

B"H
Brak

 

[Brak]

Well I think I know what the deal is.
This is just a FPW glitch/bug/error.

But by God's Grace I figured out a work around.

The code that I made works fine in a @edit. No problems. Perfect!
But there is another wonderful FPW glitch/bug/error,
when the edit box box 1 space high the problems emerge!!!

So once again by God's Grace I came up with a solution to trick it. After making the @edit box 1 space high, I set SNAP TO GRID off and click on the bottom of the box one time, there by making the @edit box a tad bigger than 1.

And you know what?

IT WORKS PERFECTLY!!!!!!!!!!!!!!!!!!!!

PRASIE THE LORD!!!!!!!!!!!!!!

I am so excited, I am bubbling over with joy.

B"H
Brak