Backspace causes a lose focus.. 7

[thatguy]

Hey there folks--

Maybe I'm searching for the wrong keywords, but I've been looking for a way to prevent backspace from causing a textbox to lose focus? I've checked the "Enter or Tab to exit fields" box on the Options->General tab and I've also included SET CONFIRM ON in my main prog (even tried it in the form's Init()), but still, when I backspace on an empty textbox, focus goes to the previous control.

I'm confused... Any thoughts?

Thanks
-- frank~

 

[StewartUK]

DoctorNix,

I entered some text in the textbox, pressed Home and then Backspace.

My next action was to try clicking on to another object on the form - any object. I got a ping from the computer and the focus stayed on the textbox.

It can be frustrating when posting threads and helping on others, in deciding how to word things and not seeing what's happening on the other person's computer. There was a recent thread where I was saying that I didn't see what the other person was seeing!

Stewart

 

[awaresoft]

Stewart/DoctorNix,

"My" post (actually the combined sum of eveyone else's posts on this topic!) appears to work fine in VFP 8.

Simple. Doesn't have any mouseclick, set notify, or empty space issues that I can see.

Malcolm

 

[StewartUK]

Nice one Malcolm. As you say, it gets around all the issues.

Stewart

 

[thatguy]

wow... surprised to see this thread still going..

in playing around with Malcolm's suggestion (kudos to Malcolm and others), i noticed that a similar action occurs with Home and End.. hitting Home when selstart = 0 takes you to the previous control and hitting End when selstart = len(allt(this.value)) takes you to the next control. perhaps amend the code to:

if (This.SelStart == 0 and (nKeyCode = 1 OR nKeyCode = 127)) OR;
	(this.SelStart = LEN(ALLTRIM(this.Value)) AND nKeyCode = 6)
	nodefault
ENDIF

personally, i feel that the cursor should stay in the box until the user hits Enter or Tab. just my thought..

-- frank~

 

[mspratt]

Hi Frank,

We are left with what M$ gives us.<g>

Regards,

Mike

 

[awaresoft]

ThatGuy!

Interesting thread, huh?! Who would have thought it would turn into such a long discussion?

Thanks for pointing out the Home and End key behavior. I had forgotten about those annoying behaviors. Your code fixes it perfectly!

Malcolm

 

[awaresoft]

MSPratt,

> We are left with what M$ gives us.<g>

Actually, that's not entirely true<g> ...

That's what I like about the OOP capabilities of VFP - we see things that need fixing, fix them in our base classes, and BAM! - its like we got a new and improved version of VFP for free.

Malcolm

 

[mspratt]

Hi Malcom,

Yup, up to a point. We are stll left with certain limitations, however (darnit).

Regards,

Mike

 

[DoctorNix]

Now that we've opened the keyboard issue, what about the <Left> and <Right> -keys ?
And another matter : if there is some text in the textbox, and the text is highlighted (=selected), then selstart = 0, so you cannot use the Backspace>. In that case, this.SelLength > 0, so now we have the following piece of code in the Keypress() :

LPARAMETERS nKeyCode, nShiftAltCtrl
*   1 = Home
*   4 = Rightarrow
*   6 = End
*  19 = Leftarrow
* 127 = Backspace
IF (This.SelStart < 1 AND this.SelLength < 1 AND INLIST(nKeyCode, 1, 19, 127)) ;
	OR (this.SelStart = LEN(this.Value) AND INLIST(nKeyCode, 4, 6))
    NODEFAULT
ENDIF

Anyone to shoot a hole in this one ?

 

[DoctorNix]

Yes, just let me shoot myself in the foot: if the vartype of this.value <> 'C', LEN(this.Value) will stir up an error.
In stead, use a memvar for the rightmost position.
This memvar has to determine what the rightmost position is.
If this.Maxlength is 0, is there a way to determine whta the rightmost position is ?
(I'm now working on a DO CASE construction, because I need an 'any type' inputfield)

 

[dbMark]

Thatguy said "I feel that the cursor should stay in the box until the user hits Enter or Tab."

In that case, Shift-Tab should be allowed. Also, Esc probably too.

dbMark

 

[awaresoft]

DoctorNix!

Great stuff - this thread keeps getting better and better. I know this thread may seem picky to some, but code like this makes an applcation feel "tight". IMO, its one of the "fit and finish" details that make an application seem professional.

> If this.Maxlength is 0, is there a way to determine what the rightmost position is?

Can you use the form's .TextWidth() property to compare the width of the string in the current font against the inner display width within the textbox ( width - 2 * border * margin - fudgefactor; fudgefactor = 0, 1 or 2)

This is a guess, I've never figured out how this works (been on my todo list) and it can be very annoying at times.

Let's keep this thread (fixing the textbox) going!

Malcolm

 

[audiopro]

I quite agree about the 'fit and finish' details being very important.
In the case of this thread I think we would need to know exactly how the input box is to react with other controls on the form before we could decide the best way of contolling the actual input box.
I have used the following code a few times for a specific purpose. The user enters letters into a box and the KEYPRESS event compares the contents of the box to a pre determined list of vars. Only when a match occurs, is the user allowed to leave the text box. Pressing RETURN or TAB runs a bit of code to check if the attempt to leave the box is valid.

*******
*Valid*
*******
if lastkey()<>9 and lastkey()<>13
return 0
endif

Keith

http://www.studiosoft.co.uk

 

[thatguy]

i'd like to voice a Yea for DoctorNix's idea of a case statement to check for type('textbox.value').. one curiosity, having a big DO CASE statement checking for each data type, then converting to text to test for a positive length.. should there be a concern for speed? running the case statement every time a key is pressed.. that's a lot of case-ing...

and i'm kind of confused by all the 'rightmost position' talk.. just to clarify - is that trying to figure where the right edge of the text is in relation to the left edge of the textbox? i guess that would solve for the case statement speed concern above..

thoughts?
-- frank~

 

[awaresoft]

If you're going to check keystrokes against data type then you will also need to coordinate with InteractiveChange so as to recognize clipboard pasted data and also with your OLEDragDrop events to recognize new data being dragged into a textbox.

I don't think speed will be an issue with the CASE statements.

Malcolm

 

[StewartUK]

Responding to DoctorNix's comment about LEN(THIS.Value) failing if the Value isn't character - I think if you put LEN(TRANSFORM(THIS.Value)) then it will be OK. Quote from the help:

Returns a character string from an expression in a format determined by a format code.

The length returned may cause a suprise - for example a logical value has a length of 3 when TRANSFORMed (".T.").


By the way, I can confirm that having a lot of code in the KeyPress or Interactive change rarely causes any visible speed defect. One of my text boxes has 160 lines of code, including opening and closing tables, in the InteractiveChange event with rarely any visible effect on typing.

Hope that helps,

Stewart
PS If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[skoko]

How about this:

In textbox keypress event:
myKey=nKeyCode

In textbox lostfocus event:
IF myKey=127
NODEFAULT
ENDIF