Numeric data entry from right to left 2

[SitesMasstec]

Hello colleagues!

I have a text box for inputing a currency value, for example 1234.95

When I use any calculator the numbers are displayed from right to left:
[pre]
1
12
123
1234
1234.
1234.9
1234.95
[/pre]
Is it possible to have the same behavior in a text box in VFP?


Thank you,
SitesMasstec

 

[Chris Miller]

1) Your description contradicts itself, but when the textbox classes don't act as you like, it's perhaps a misunderstanding about how to configure them. Well, you give up early.

2) Z only empties the textbox, when the value is 0, so it's not hiding the inputmask, always. Also, the inputmask is not shown as value, it is just guiding what can be entered, if the inputmask is shown, there's something wrong with how you setup the textbox.

Also: Set the controlsource to a numeric field or variable, or initialize the value to 0.00 or another number. Otherwise you'll get a string, not a number.

Chriss

 

[TamarGranor]

I just want to add to this whole discussion that the two properties InputMask and Format are used for the one thing that the Picture clause in pre-Visual FoxPro did. Format is for the part that used to come at the beginning and be preceded with "@"; InputMask is for the part that came at the end.

Tamar

 

[Chris Miller]

Yes, and you still have Format and Inputmask as a "picture" in Transform as the cFormatCodes parameter:

? Transform(0,'@Z 999,999,999.99')
? Transform(0,'@R 999,999,999.99')
? Transform(12345.67,'@Z 999,999,999.99')
? Transform(12345.67,'@R 999,999,999.99')

SitesMasstex, and the topic of Transform also tells you in shich cases you get astrerisks, for example:

When the expression value is longer than the width of the numeric field, Visual FoxPro forces the value to fit by performing the following steps:

Truncate decimal places and round the remaining decimal portion of the field.

If the value does not fit, store the field contents using scientific notation.

If the value still does not fit, replace the field contents with [highlight #FCE94F]asterisks[/highlight].

So your problem may have been you use the calculator style textbox but also set the inputmask and set it too short. You know better than us. I think the calculator style textbox was programmed for (almost) any length up to the range of floating point, 16 places. But if you use a class and change some properties the code might not work as expected any more. Just one possible explanation of why you didn't get what you want from the class.

Chriss

 

[SitesMasstec]

Yes, Chris, even if in the procedure LostFocus I use

this.InputMask='999,999.999,99'    && longer InputMask

Then,when executing, if I enter 123456,78 (my decimal point is ','), I got this:

This is why I gave up about using calculator data entry mode (at least for now, until I completely understand the class or why it shows unexpected results, as the one showed above).

So, I will stick to the VFP TextBox (from Standard class library).

I am trying, in the standard TextBox, when it got focus, that nothing appears inside the TextBox (completely empty, no 0,00).
So that, just after I type 12345,67 inside it and go to another object (lost focus) it shows 12.345,67 in the TextBox.


Thank you,
SitesMasstec

 

[Chris Miller]

SitesMasstec,

you set the inputmask once and for all in the form designer before the form even runs.
It's static, you set it once and don't change it.

Also, you don't set the inputmak property at all, if you use the classes, the classe will handle that for themselves and if you write code in events and don't DODEFAULT(), then you break the class, as you override its behavior and of course they don't work, you're sabotaging them.

Chriss

 

[Mike Lewis]

I just want to add to this whole discussion that the two properties InputMask and Format are used for the one thing that the Picture clause in pre-Visual FoxPro did.

Tamar, that reminds me of something that I have been meaning to mention to you for some time.

The entry for the Format property in HackFox includes this line in the example code:

ThisForm.txtSSN.[highlight #FCE94F]Picture[/highlight] = "999-99-999"

Somehow the word "Picture" has crept in, in place of "InputMask" - presumably left over from your 2.x doc.

I'm not suggesting this should be changed at this late stage of course, but I thought it worth pointing out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Also, you have a wrong inputmask, again.

this.InputMask='999,999.999,99'

a) you set this in the properties window in the form designer or b) if you absolutely want to write code, then write it in the INIT of the textbox.
b) The inputmask has to be 999,999,999.99

, for thousands separators and . for decimal point, even if the decimal point in your coutry is the , and the thousands separator is the . VFP will apply the regional settings omce you SET SYSFORMATS ON, but just like you need to use the . for decimal point in code, the meaning of it in the inputmask is the decimal point, that doesn't change with regionsl settings, what changes is that you get the . displayed as thousands separator and , as decimal point, even though that's the inverse of the inputmask. So the inputmaks is US format, just like numbers in code, except numbers in code can't have thousands separators at all.

ad a) I already told you this earlier:

you don't have to set the Inputmask in the GotFocus event, you can set it in the form designer at design time and at run time it just works all the time, once it is set and you don't have to wait for the control to get focus to set the inputmask, nor do you need to remove it when the control loses focus. It makes no sense to do that.

And Mike already confirmed it

That's a good point. If you keep the mask in force the whole time, the formatting (the dot and the commas) will be visible while the user is entering data, but they do not have to be explicitly typed. Just type the digits as usual.

When you set the inputmask while you deisign the form, you dopn't need any code at all setting it. It's just always present and does its job.

With an inputmask that has the decimal point used, the user can enter a number as is usual pressing the [,] key if the comma is the decimal point in your region, will put the text cursor to the place to enter the decimal places.

I already also told you:

Set the controlsource to a numeric field or variable, or initialize the value to 0.00 or another number. Otherwise you'll get a string, not a number.

If you first enter a numbmer and then apply a mask, it's no wonder you get nonsense. And that's what you do when you set it in Lostfocus. Especially when the textbox is unbound and the value will be a string, not a number. Applying an inputmask as aftermath to a string is not working correctly at all.

Chriss

 

[SitesMasstec]

Oh, I am sorry, I corrected it in the LostFocus property:

this.InputMask='999,999,999.99'

But I got this bad result:

Thank you,
SitesMasstec

 

[Chris Miller]

Did you read all I said?

Set the controlsource to a numeric field or variable, or initialize the value to 0.00 or another number. Otherwise you'll get a string, not a number.

To show an example:

_screen.addobject("Text1","Textbox")
_screen.Text1.Inputmask = '999,999,999.99' 
_screen.Text1.Value = 12345.67
_screen.Text1.visible = .t.

Display in US format:
12,345.67

If instead you never set the value, the default value of a textbox is an empty string, not a number. And what happens, if you set the value to the same number as a string is that:

_screen.Text1.Value = "12345.67"

Display in US format:
123,5.6, .
In short: nonsense

What did I tell you to do, SitesMasstec?

To take the stress out of it: We're all here to help, not to torture, but what would it do to you if you give advice to sombody, that is ignored? Multiple times?

You can also learn from this code, why the same inputmask creates differrent results, depending on what you feed in:

? Transform('12345.67','@Z 999,999,999.99')
? Transform(12345.67,'@Z 999,999,999.99')

Chriss

 

[SitesMasstec]

I am trying to understand all these posts from Mike, Chriss (many thanks to both). It will take some time.

This is because, for now, I decided to use the standard TextBox packed in VFP.

Important to say, I will not adopt the calendar style anymore (entering data from right to left).

I just want to enter 123456.78 and after go out of the textbox it shows 123,456.78. When I use Format Z it shows the textbox empty. Thats's ok.
But when I enter in the textbox object to type a value, it shows 0.00. I am trying to have the textbox completely empty until I begin to type numbers.

Thank you,
SitesMasstec

 

[Chris Miller]

I am trying to have the textbox completely empty until I begin to type numbers.

Aha, at least we're getting somewhere.

That's a very specific demand, I don't see how you get that. If you want a simple textbox without using a class with much code and want to use the inputmask feature of VFP, then you don't get around specifying a numeric value, and indeed, even with Format "Z", once you focus the textbox the display value will switch to 0.00. You could call it a bug perhaps, but you know there is nobody at Microsoft changing VFP, not even a little bit.

So, stick to your demand, then you likekly will to program for the special cases like that instance when the textbox get's first focus, and your code will get longer than even that of Kilofox from Andy Kramek and Marcia Atkins, two Foxpro experts that were MVPs. Every single one has more knowledge than me. Or you have to lower your demands.

It's not a solution to not use the inputmask, that's for sure, because without an inputmask, the characters the user can enter are not limited, and then you don't just have the problem that the inputmask can't be converted to the desired result, the input then is not restricted to only digits, one decimal point or comma and perhaps an overall size or range.

You only set textbox.value to 0.00 and the inputmask to 999,999,999.99 and you get the following behavior for free, without any line of code:
a) the user can enter a sign + or -, the user can enter any number of digits, when the number of digits rises to 4 a first thousands separator is shown, when you reach a 7 digit number the second thosands separator is shown. Now at any moment the user enters a decimal point (or comma), the nmumber entered so far is becoming shown right before the decimal point (or comma), the text cursor will jump right after the deicmal point (or comma) and the user types the decimal places. It's almost impossible to have any more comfortable input, ubnless you program an AI that predicts what the user will type in next.

You don't even imagine what code would be necessary without the inputmask property to get this guidance and helpful display of the number entered in a human readable format with the thousands separator as helpful assurance the number entered has the right magnitude and you don't error by a factor of 10 or even 100.

Now you come along and say you don't like the inital 0.00 to be shown. You don't show any decency, if you reject the whole system just because you don't like this one detail.

And yes, you can program a textbox that allows what you initially posted in all your steps, but what you write there is also merely a sketch of what the behavior is, you're then not even having the decency to detail what you want to have as the exact description of what someone should program. Instead, anything you're offered is rejected by you. You lost me.

Chriss

 

[TamarGranor]

Wow, Mike! Can't believe we missed that (and no one told us) through 3 versions.

I guess we ought to fix it in the online open source version. If only I remembered how. ;-)

Tamar

 

[SitesMasstec]

Chris:

When someone, mainly with less knowledge (as it is my case) wish to accomplish a task, during the task, even with the help of others (expert people like you, Mike and Tamar) can experience difficulties in learning what expert people are saying.

Well, I am very grateful for you and Mike for showing me classes from KiloFox and LevelExtreme to accomplish the task, which, I will be trying to understand reading all this posts again and again. It will take me some time to get out from errors I had with these two third party classes.

So, for now, I will be using the standard TextBox. Well, as I understood in your last post, it will be very difficult to get the 0.00 from the standard TextBox class as the focus is on it. So, I will not try it anymnore, also because in the last two hours I did not accomplish it.



Thank you,
SitesMasstec

 

[Chris Miller]

it will be very difficult to get the 0.00 from the standard TextBox class as the focus is on it. So, I will not try it anymnore,

It's not impossible, you could set the forecolor to the backcolor so the 0.00 is not seen until the user enters the first digit and then set the forecolor to black in interactivechange.

That's even a completely untechnical solution, you just have to think about what you want and ways to achieve it, the textbox having no characters in it is only one way of so many more I could think of. If you'
re that unimaginative to not get any idea how to solve a problem, then I don't know what to say anymore.

That's OCD, and it's a fom of OCD that's not worth having empathy about. It's nuts. It's unreal, it's disconnection from reality.

I don't even know what thought process is behind this. A 0.00 is a hint to the user this box exepcts a numeric input. It's good that this is shown when the textbox becomes active. You can of course label the textbox, so it's unmistakably clear the user will need to enter a numeric value, true. but what's actually bad about a 0.00. Do you think a user confronted with a 0.00 appearing when the box was empty before will die from a shock of the surprise something appears? Do you think it will hinder them to enter a value as they see "Oh, this box is already filled". How do you think of your users?

Chriss

 

[Chris Miller]

Now things have settled a bit for me, let me guess what happened.

You didn't overlook what I was saying, you were trying the value=0.00, but were dissatisfied with the result. You were not coming back to tell this, but that's a thing that made me upset.

Instead you may have tried a ton of things. You didn't see that the difference of the inputmask result display value comes from the data type of the textbox being character/string instead of numeric. I can only tell you that, if you post feedback.

First you have to realize that the datatype of the textbox has to be numeric. and you can deduce that from me telling you that the claue has to be initialized to 0.00 or the textbox has to be set to a controlsource of a numeric field or variable. That's telling that. There is no other way of forcing the datatype to be numeric.

If you get stuck on such a detail, that 0,00 appears, you're losing the overall goal that the user should be able to enter a number with guidance of several helpful behaviors of the inputmak, not being able to enter a letter or other non numeric part of input, for example. And then overall look at the effect. The user can easily work with this textbox, can't he? So why insist on such a detail that is absolutely pointless. You're getting stuck at an unimportant detail while you alread yat the goal.

And the goal must be, to achieve what the classes achieve without much ado, but then you have to accept compromises, or you don't see the woods for the trees, because you still don't have comprehended that the massive code put into the numeric textbox class has its reasons in similar details, that don't work with a codeless textbox just with an inputmask set. You're not failing of knowing too little about Foxpro, you're failing on your perfectionism.

Chriss

 

[SitesMasstec]

My spirit is more clarified now, Chris, after reading your words, thanks.

So I stick to this standard TextBox, with some custom changes (I think this is better than what I had wished, calculator mode data entry):

Note: Decimal point is , and separator is . in my country.


Properties:

- Format: Z

- GotFocus:

this.InputMask='999999.99'

- LostFocus:

this.InputMask='999,999.99'

- Value: 0.00


Thank you,
SitesMasstec

 

[Chris Miller]

I wonder why you do without the thousand separators while the textbox has focus, because I think that feedback is valuable to the user while entering the number, not just as aftermath. But if you're good with what you got by these means, I'm fine with that.

Chriss

 

[SitesMasstec]

Because it becomes confusing to the user.

Let's supose the user is going to enter 1234,56 (, is my decimal separator). The user is typing 1234, it is showing:

Only when the user finishes typing the whole number, it will show 1.234,56

Thank you,
SitesMasstec

 

[Chris Miller]

If your regional settings in Windows are reflecting that, he inputmask would not how that behavior, once you do
SET SYSFORMATS ON.

If not, you can explicitly set
SET POINT ','
SET SEPARATOR '.'

Maybe also check what the key on the numpad will be, dot or comma.

And then entering 1234,56 will cause these displays:

1
12
123
123.4 (here the first spearator dot is displayed)
1.234,
1.234,5
1.234,56

Okay, I understand you find this confusing, but once the decimal comma is entered, the number is adjusted correctly and the separator dot appears after the 1. Before you enter the comma, the length of the number is not yet fixed. Well, I think you would expect this as more appropriate, right?

1
12
123
1.234 (display the separator dot at the correct place interpreting the so digits entered so far as one thousand two hundred and thirty four)
1.234,
1.234,5
1.234,56

Okay, I understand why you don't like the handlig of separators. I'd still argue that the wrong display of 123.4 is better than 1234, even though 4 digits are still short enough to not misread the magnitude. 123.4 looks like VFP expects input of a 6 digit number. Well, yes, but you always get the correct positioning once you enter the decimal comma.

So, there are pros and cons, right?

For the matter of unwanted formatting I think you found a good compromise of not using separator characters in the inputmask during input. If the number entered would go to millions or billions I would consider the separators better, even if they are at preliminary wrong positions. But that's a matter of taste.

Chriss

 

[Chris Miller]

One last thing, since you got the weord results like 12,345.6 or ***,***.**. with the kilofox or the class by Rick Borup from levelextreme is applying what you learned here during this discussion.
1. Preset the value to 0.00 or set controlsource to a numeric field of a cursor or table
2. SET SYSFORMATS ON to get your country standard for separators and decimal comma or SET POINT TO ',' and SET SPEARATOR TO '.'

I'm pretty sure the classes will work, then.

Also: Only set the inputmask when the doczumentation of the class tells you to do that, for specifying a maximum range, maybe there are other class properties to be set.
And don't override any methods or events. If you write code in gotfocus or lostfocus or interactivechange you likely sabotage what the class code does and break the class that way. Even if you see the methods empty, that's standard, you only see the class code, when you open the class in the class designer, when you add a class to a form that class code is only seen when you use the "view parent code" button of the code editor.

Chriss