Preventing or disabling the backtick-escape "feature" in foxpro 1

[nqramjets]

We've recently run into a scenario where a user had accidentally hit the backtick character while doing data entry in an editbox (VFP9). In this case they actually typed the sequence [kbd]` [/kbd] (backtick - space), which result in a NUL char '\0' being inserted.

This edit box is bound to a remote view memo field, and caused a SQL failure during the [tt]TABLEUPDATE()[/tt]

Ideally there would be some sort of global FoxPro [tt]SET[/tt]ting which would disable this, but I have had no luck finding it if it exists.

Besides going through and handling these characters during data entry in [tt]KeyPress[/tt] and issuing a [tt]NODEFAULT[/tt] is there any other more elegant way if preventing this that I haven't thought of yet?

 

[Olaf Doschke]

Well, first of all, a backtick is an accent character waiting for a letter to be typed, eg è and when you type a space that results in just a backtick, not in NULL, at least not on the VFP side.

It wouldn't ever be a problem with parameterized views and if your VFP code generates query strings you could always simply strip off ` via CHRTRAN or STRTRAN.

The way you'd prevent .NULL. entry is ON KEY LABEL whatever *, that means execute a comment and thus very generally suppress that key or key combination.

The last two methods obviously need change in the VFP code, if you only have a binary/executable you can't make a setting to prevent that.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[nqramjets]

Hmm, perhaps your keyboard layout is different from mine, because for me a backtick-space combination results in [tt]CHR(0)[/tt] every time.

Either way, the [tt]ON KEY LABEL[/tt] is a good idea. I'm a bit reluctant to try and handle it in our framework editbox level because we have several with instance-level code. (Not that it wouldn't work, just would require a lot more effort)

I thought of the [tt]CHRTRAN()[/tt] idea too. In order to implement that generically I could not come up with a way of doing it that would not result in a bunch of redundant calls on data that is already good clean.

I think I'll try the [tt]ON KEY LABEL[/tt] and see if that works. Thanks Olaf!

 

[Mike Lewis]

perhaps your keyboard layout is different from mine

It would be interesting to know which keyboard layout you are using.

I am using the standard US layout. Normally, in most Windows apps, a backtick works as expected, that is, it generates CHR(96) - a grave accent. But it VFP, it seems to work as a dead key, as Olaf described. However, typing backtick followed by a lower case e doesn't generate CHR(232) - e grave - but rather CHR(5). I've no idea why. Other dead key combinations give other codes. To actually type a grave accent, I would have to press the backtick twice.

On that basis, using CHRTRAN() to strip out the unwanted keystrokes probably won't work. ON KEY LABEL sounds like a better bet.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Interesting Mike, to me (German keyboard layout) the backtick is a character situated two keys right of the 0 in the top row of keys (not the numpad) and it has the "dead" or delayed effect as it waits for which character you want to be with the grave accent or whether you want the backtick itself. It's a character you get with SHIFT+key, not ALT or ALT GR and works like ^ on the left most key of that row.

I can confirm though, I need two backticks to get the backtick in the command window or in a code editor, and backtick followed by space causes nothing visually there. But backtick+space typed into a textbox I get the pure backtick character CHR(96).

So this might even depend on what has focus.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

Olaf, for what it's with, on my standard US keyboard, the backtick is at the extreme left end of the top row of numeric keys, to the immediate left of the 1. I've done some more testing since my previous post. The behaviour I described (acting as a dead key) seems only to apply in VFP (I tested this in the VFP file editor, command window and editbox). In other apps, it simply types a grave accent, with no deadkey behaviour.

I see that on a standard British keyboard, the backtick is in the same position as in the US, but shares the key with a pipe character. I don't know how that works. I'll test it next time I connect my British keyboard.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads