Formatting Numeric Input

[guest]

I have edited the code and removed the unnecessary line, leaving a blank line in its place.

You seem to have deleted one of the superfluous lines, but left the other!

Richard.

[RNBW]

You've just beaten me to it. I've realised that the second line should go too. I've edited the code so, hopefully, that should be it.

Again, thank you for picking up the problem.

The reason for the superfluous lines is that I did the code for checking for double "." first and then copied, pasted and modified it for "-", but then realised that this didn't dictate that a "-" could only be the first character. I slotted in the line to do this, not realising that this prevented a second "-" anyway. So I had the superfluous code.

Sorted now.

[tsh73]

I'm still puzzled by this code.

What does "a=8" do?
Just clears that code, in effect removing character?
So almost anything besides 8 will do?
(last line in effect allows only ".","-" and digits - so using anything else instead of 8 will do the same)

Now, t1 is not used. Something is left? (kind of taken care of while I typed)

Also I noticed than I have a number with a digit say 123.456
- then move cursor and place another dot inside 12.3.456
- string got truncated from second dot. 12.3
It really looks weird, does it?

[RNBW]

Hi tsh73

You're right, a = 8 is the equivalent of a$ = chr$(8), which is indeed a backspace that overwrites the offending digit and allows you to carry on with your input. I must be backspace, because anything else would be entered as you input it.

The code doesn't allow the input of a ","

With the example you give 123.456 if you move the cursor to after the 2, you do indeed get 12.3. I think this is because the input was effectively complete and what you have done is change the input and because there can only be one "." it has generated a backspace and overwritten the second "." whilst also removing all characters after the backspace in a new entry.

You may have identified a deficiency in the code. Perhaps it needs to be set in a loop, with a chr$(13) {Enter] required to complete it or perhaps a tab if there was more than one textbox, which would put the focus into another textbox. However, I've tried it in a grid using the tab to move the focus to another textbox and the result is the same. The program is expecting a continuous input into the textbox and if you move the cursor and enter another character it treats it as a new entry, taking into account all the original rules. For instance, if you enter a "-" it simply deletes it. If you enter say, 3, it types 3. But if you enter "." it considers this as the last character and deletes everything after it, because there can only be one ".", allowing you to enter further characters after the "."

If it didn't check input as it was being entered and you entered a whole string, say 123.456 and then went back and entered "." after the 2, I would expect well written code to come up with a message box pointing out the error and asking you to correct it. My code simply says only one decimal point, so if this is now your entry I'm deleting everything after it and giving you the opportunity to enter further code. Let's say you've now got 12.3 and move the cursor before the "." you would get 123.3 and if you then deleted the last 3 you would get 123. and you could then type the 456 to end with 123.456

One of the possible ways around it would be put up an error message when you type the second "." asking if this is what you want to do and to correct the rest of the input.

Sorry about the ramble, I'm writing it as I'm going along.

[guest]

The program is expecting a continuous input into the textbox and if you move the cursor and enter another character it treats it as a new entry, taking into account all the original rules.

Any 'entry filtering' ideally needs to be compatible with the normal input editing operations that the user might perform: repositioning the caret with the mouse, tabbing betwen input fields, typing backspace and delete etc.

Richard.

[RNBW]

Richard
The input is capable of being edited, but there is the drawback of going back and inserting a decimal point before the of already entered, with the effect described. I think it is fair to say that if you did this, you would need to change the input after the decimal point anyway.

Other aspects of editing are accepted by the code. A minute in the middle of the input is just deleted and any other valid character can be inserted.

My personal feeling is that error messages could be set up to cover inserting a second decimal point, but anyone inserting a second decimal point would immediately see the effect, which is to delete all characters after it.

What do you think would be the best way of dealing with it?

Ray

[guest]

What do you think would be the best way of dealing with it?

Let's assume the user has entered a number (including a decimal point) but then realises the decimal point is in the wrong place. He could first delete the old decimal point and then insert a new one - presumably that would work as expected. Alternatively he could insert a new decimal point in the correct place and then delete the old one; if I've understood you correctly that will not give the expected result. Ideally, I would want the two approaches to have the same effect; that could include the first decimal point automatically being deleted by the insertion of the second one (but leaving all the other digits unchanged). I would not expect it to make a difference whether the new DP is to the left or the right of the old one.

Richard.

[RNBW]

Richard

Let's assume the user has entered a number (including a decimal point) but then realises the decimal point is in the wrong place. He could first delete the old decimal point and then insert a new one - presumably that would work as expected. Alternatively he could insert a new decimal point in the correct place and then delete the old one; if I've understood you correctly that will not give the expected result. Ideally, I would want the two approaches to have the same effect; that could include the first decimal point automatically being deleted by the insertion of the second one (but leaving all the other digits unchanged). I would not expect it to make a difference whether the new DP is to the left or the right of the old one.

I hear what you say and in the ideal world, that's what would happen. The problem is, how to achieve it. I've been playing around with it and can't get my head around how it would work. The only thing I could think of was to trap the insertion of a second decimal point and bring up an error message that pointed out the two decimal points and to delete which was inappropriate - then the problem is to produce the code.

I've also done a bit of testing elsewhere. I checked how Microsoft Excel dealt with two decimal points. I formatted a cell in two ways, one as text and one as numeric. Both allowed two decimal points. I must say I was a bit surprised. Before I retired I spent a lot of time with spreadsheets and I must never have tried to enter two decimal points, because I just didn't know this happened.

I also gave my wife a test. I listed 20 numbers, some with a minus sign, some with a decimal point and some just numbers. Alongside the listed numbers I listed numbers I wanted her to change them to. And then I watched. Getting rid of the minus was easy, just a delete. Changing numbers: she was a bit variable on this - sometimes she deleted the number to be changed and sometimes she added the new number before deleting the old. Changing the position of the decimal point: she deleted the existing one first every time before adding the new. After that I ran the program and asked her to enter 123.456 and then to change it to 12.3456. She deleted the exiting decimal point and then added the new. I then asked her if she always did it this way. She said she didn't know, she just did it.

If you don't do that and enter a second decimal point, the program always forces a deletion of the second decimal point and deletes all numbers after the remaining second point, forcing you to complete the edit of the number.

It seems to be beyond me. Can someone come up with code that will allow an edit as described by Richard?

Ray

[tsh73]

I'm afraid that couldn't be done quite right.
Do we have caret position (insertion point)?
If not, how program could tell which dot is old and which new?

Without that we only could remove one dot - first or last positionally, arbitrary choice to be made
And insertion point will move to the end of current text.

Here what I came with

Code: Select all

function num$(d$)
    t = 0': t1 =0  't1 is not used
    for i=1 to len(d$)
        a=asc(mid$(d$,i,1))
        if a = 46 then t = t + 1
        'if t > 1 then a = 77                  'this one deleted everything after second dot
        if (a = 46) and (t > 1) then a = 77    'only DOT after FIRST is cleared
        if a = 45 and i>1 then a = 77          'so really almost anything do, not just 8
        
        
        if a = 46 and i = 1 then num$ = "0" + num$
        if a = 45 or a = 46 or a>47 and a<58 then num$=num$+chr$(a)
    next

end function

PS
and about

You're right, a = 8 is the equivalent of a$ = chr$(8), which is indeed a backspace that overwrites the offending digit and allows you to carry on with your input. I must be backspace, because anything else would be entered as you input it.

As I noted, line

Code: Select all

 if a = 45 or a = 46 or a>47 and a<58 then num$=num$+chr$(a)

does not allow anything but digits, "-" and "." to pass. So "chr$(8), which is indeed a backspace " never actually made to textbox.
So I changed "8" to "77" - no difference.

PS2
So

Code: Select all

if a = 46 and i = 1 then num$ = "0" + num$

changes ".123" to "0.123"
Should "-.123" be somehow changed as well?

[guest]

Do we have caret position (insertion point)?

Presumably yes: if it's a Textbox EM_GETSEL returns that.

If not, how program could tell which dot is old and which new?

A common approach is to read the contents of the Textbox periodically, in a TIMER handler, then you can compare what's in the textbox now with what was in it a short time ago and therefore deduce what and where the change is.

and about "You're right, a = 8 is the equivalent of a$ = chr$(8), which is indeed a backspace that overwrites the offending digit" ... a backspace never actually made to textbox.

I didn't understand Ray's comment either. I agree with you that any value other than the code for a digit or decimal point would have the same effect.

Richard.