What len(thisform.text1.value) will return? 3

[greathope123]

Hi,

In VFP, I found
?len(thisform.text1.value)
returned something related to the length of the text1 box, not the length of the string in the box.

Anything I was missing??

 

[Olaf Doschke]

No and yes. It will return the length of the value property. And there is no textbox length as in input type text html, only indierectly: If there is an Inputmask with a certain length, that would be fixed length, for example. Look at the value. If you want the length of the value after trimming away spaces, then do alltrim().

Bye, Olaf.

 

[greathope123]

Thank you.

I did not input any space, why I need to trim away spaces?
I also tried to make the box longer (without change the string), I got a bigger return value!

 

[Olaf Doschke]

So you say you have a native textbox and changed nothing but the width and it returns a string of spaces by default? I have missed that, since I always use textboxes with controlsource, and then that determines the value. Anyway, if that's the case, then, yes, you have to trim.

Nothing else set? Inputmask? MaxLength? The Value itself?

Bye, Olaf.

 

[Mike Lewis]

I did not input any space, why I need to trim away spaces?

Because, if the textbox is bound to a field in a table, the value will be padded with spaces, to bring it up to the width of the field.

In general, you should always trim the value when you want to determine its length. If a user types a value into the textbox, you can never be sure whether he has added extra spaces at the end (or even at the beginning). There may be no reason for him to do that, but it's an easy thing to do inadvertently.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If Mike is right and you indeed use the controlsource, a varchar field will be empty, if blank, for example. I usually even bind textboxes for entry of a filter to a oFilterparam.property and that also won't default to spaces.

Bye, Olaf.

 

[greathope123]

Thanks a lot for two responses above.

I have just made a test code for Command1:

?thisform.text1.width
?thisform.text2.width
?len(thisform.text1.value)
?len(thisform.text2.value)
?thisform.text1.value=thisform.text2.value

Run the program and typed 12345 into Text1 and Text2 very carefully, after click Command1, I got:
97
120
17
21
.F.

 

[Mike Lewis]

You can't compare text1.Width with LEN(.Text1.Value).

The width is in pixels; the value is in characters.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

If you want to know the length of the value typed into a Form's Textbox, you probably should be using:

?LEN(ALLTRIM(thisform.text1.[u]text[/u]))

And regardless if you type Numeric characters or Alpha characters (or a combination of the two) into the Textbox, you will get the length of your entered characters.

Good Luck,
JRB-Bldr

 

[greathope123]

To MikeLewis,

Sorry, I didn't explain what I want to do in my above program!
No, I didn't try to compare .text1.width with len(.text1.value)!

I tried to compare len(.text1.value) with len(.text2.value) and to compare .text1.value with .text2.value
Although I typed the same string "12345" into text1 and text2
1. len(.text1.value) is not equal to 5
2. len(.text2.value) is not equal to 5
3. .text1.value is not equal to .text2.value

 

[greathope123]

To jrbbldr,

Thank you for your suggestion.

I have just tested:

?thisform.text1.width
?thisform.text2.width
?len(thisform.text1.text)
?len(thisform.text2.text)
?thisform.text1.text=thisform.text2.text

and got the same result!

Can we assume that .text1.text (and .text2.text) must be jointed automatically by something which can be removed by alltrim() althoug they are not spaces?

 

[JRB-Bldr]

OK.

But what is the goal of your question?

To evaluate the length of the characters entered into a Form's Textbox?
Or to just have a better understanding of how things work?

The .Text value of Textbox will depend on at what point you evaluate it.
* Immediately after Initialization (most often done in the Form's Init Event)
* After a user has made an entry

Have you inserted Breakpoints or SET STEP ON commands into your code at various points and examined the various values in the VFP Watch Window?

If not, then maybe you might want to try that to see what you get.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

typed 12345 into Text1 and Text2

If you typed 12345 into both Text1 and Text2 AND if you put either Breakpoints or SET STEP ON commands into the Textbox's Valid Events of your code, you should be able to go to the VFP Watch window and examine both the properties of both those objects.

[b]?len(thisform.text1.text)[/b]  && Will give you the entered text padded out to the Non-Trimmed Length of the object

[b]?len(thisform.text2.text)[/b] && Same as above

What are the ControlSource's for each Textbox?
* If defined, are they each the same Length?
* If not defined, then are the Textbox Length's the same?

?thisform.text1.text=thisform.text2.text   && The amount of 'pad-out' depends on how you [u]Initialized[/u] the textboxes.  If different, then the results are different unless you use ALLTRIM()

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

Width is the visual width in pixels and has nothing to do with the value length at all.

Bye, Olaf.

 

[greathope123]

To jrbbldr,

Thank you.

After I type the string into text1, immediately, I click Command1. The code in Command1 is
?len(thisform.text1.text)

My proplem came from code

use table1
locate for username=thisform.text1.value
if found()
......

Although I typed correct username into text1, the code cannot find it.
Now, I realised we must code like this

use table1
locate for alltrim(username)=alltrim(thisform.text1.value)
if found()
......

but, why? A VFP bug?

 

[Olaf Doschke]

OK, tested myself.

Actually, the width has an influence on the len of the value/text, I see that, too. Even if you use a textbox unbound, even if you don't type anything, the value defaults to a string of spaces filling it.

So what now? Nobody can change that. Bind to a C(50) field and len will always be 50. That's what you do anyway.

Bye, Olaf.

 

[greathope123]

To OlafDoschke,

Thank you.

I hope "Width is the visual width in pixels and has nothing to do with the value length at all".
However, in my test code the length of "12345" looks related with the width of the textbox:
if the widths of both textboxes are the same, the lengths (and the values) of "12345" will be the same, otherwise thay are not the same

 

[Olaf Doschke]

I think it's designed that way, so the value of unbound tesxtboxes is prefilled with a space string. That way you can click anywhere in the textbox and type. You usually do alltrim the value or bind to a table field anyway, and then this is no problem at all, in the end you compare table1.field2=table2.field1 and not control.values or control.texts.

Bye, Olaf.

 

[Mike Lewis]

use table1
locate for alltrim(username)=alltrim(thisform.text1.value)
if found()
......

but, why? A VFP bug?

I can only say that the above code is the way we have always done it. In other words, always trim any fields or values involved in a string comparison. It's one of the first things I teach on my VFP course, and it's something that's ingrained in the minds of most VFP developers.

Actually, I'd go a bit further, and use a double-equals sign for the comparison, to avoid the risk of a substring match. Plus I'd wrap both terms in an UPPER() - unless I specifically wanted a case-sensitive comparison.

I understand what you are asking. You are questionning why this should be necessary. I'm not sure how to answer that. But it's certainly not a bug.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

use table1
locate for username=thisform.text1.value

First of all, after putting a data table in USE, you should do a SELECT to ensure that the intended table is the one that is being worked upon.

use table1
[b]SELECT Table1[/b]
locate for username=thisform.text1.value

Next, the ability to use a LOCATE like you are doing can be dependent on a number of 'other' environment parameters.

Do you have SET EXACT ON ?
* You can check by using ?SET('EXACT')

If so, then unless the full value of Username (including trailing spaces) is Exactly equal to the full value of thisform.text1.value (including trailing spaces) then LOCATE will NOT find a match.

For example:
MyTable.UserID = "12345 " && Note number of trailing spaces
cFindThis = "12345 " && Note different number of trailing spaces

LOCATE FOR MyTable.UserID = cFindThis
will not result in a FOUND() if SET EXACT ON

Actually, although I generally prefer to use a SEEK on an Indexed field, when I do a LOCATE for characters (whether numeric or alpha characters) I not only use ALLTRIM() but I also generally use UPPER() so as to eliminate any possible issues with character Upper/Lower Case mis-match.

Example:
LOCATE FOR ALLTRIM(UPPER(ThisField)) == ALLTRIM(UPPER(cFindThis))
* Also note use of double equal signs '==' which means EXACTLY Matches

That will better ensure that a match can be found if it exists at all.

Good Luck,
JRB-Bldr