Checking for empty numeric fields

[John Castle]

I need to prevent a user entering numbers on a form if they have not input an initial number :

Allow This? NO OK OK OK

Kg to Check: blank 0 0 0
Kg Accepted: 1000 1000 1000 990
Kg Rejected: blank blank blank 10

i.e. I want to force the user to enter a number in the 'Kg to Check' field before entering numbers in 'Kg Accepted' and
or 'Kg Rejected' fields. But initially all these fields will be blank when the data is input/amended. Only later are these filled.

I have tried on table field rules testing for null value and ditto on the form but it seems Alpha does not know the difference between nothing and the figure 0.

I also tried testing for a field of length 0 - i.e. no contents as opposed to containing figure 0 - giving a length of 1 i.e. contents.

How can I get round this?

[JerryBrightbill]

RE: Checking for empty numeric fields

John

Unfortunately, the number 0 in the computer world is not exactly 0. When evaluated, there is always some small value out at some rediculous decimal place. Instead of checking for 0, check for round(value,2) = 0. If you are always using whole numbers, use round(value,0) = 0.

The same issue occurs in math with currency. If you don't round off, 1 may not equal a calculated 1. The checkbook doesn't balance even though it looks like it should.

Jerry

[CALocklin]

RE: Checking for empty numeric fields

Worse yet, unless this has been changed relatively recently, if you read the value of a control that is blank but defined as a numeric value, the result is some huge number. (The data in the table is OK - i.e., 0 - but reading the value directly from the form object will be wrong.) Consequently, I would initialize any Number field to a default value whenever humanly possible.

In most cases, the value could be set to 0. In one case where 0 was a reasonable data value, I assigned 999 as the default because the maximum normal value was less than 100. Unfortunately, this required some additional coding to make sure the number 999 wasn't used in any calculations or displayed on forms - bummer.

The other alternative I've tried is never getting the value of a numeric field with:
var = "Formname>:"ObjectName>.value
but, instead:
varc = "Formname>:"ObjectName>.text
var = val(varc)

Now, back to the original question...

Assume your 'top' 4 objects are named Check1, Check2, Check3, and Check4 and the next 'row' is named Accepted1, Accepted2, etc.
You could add a script to the CanArrive event of Accepted1 that says:
IF parentform:Check1.text"OK"
cancel()
END IF

This would make it impossible for the user to access (arrive at) the Accepted1 field at all until the value in Check1 box was "OK".

[CALocklin]

RE: Checking for empty numeric fields

Oops! That was supposed to be "displayed on reports"

[CALocklin]

RE: Checking for empty numeric fields

I had to check it... After a few tests to get close, the following returns a value higher than 1 x 10^308 on my system if the numeric field called 'mbr_agef' is left blank. (Yes, that's a one followed by 308 zeroes - and, no, I don't know, or care, what that number would be called.)

m_age = parentform:mbr_agef.value
FOR x = 300 to 330
IF m_age > 1*10^x
ui_msg_box( "HUGE", str(x) )
ELSE
ui_msg_box( "MEMBER AGE", str(m_age,20,0)+str(x) )
END IF
NEXT

At 309 it attempts to show the value but can only display 15 vertical bars instead.

[Blake]

RE: Checking for empty numeric fields

>

Waitaminute. What?

I mean, yeah, at the transistor level, there's always some charge, but integer processing has been a part of the '86 architecture from the beginning.

And we're operating WAY above that in A5. In actual dBase file a zero is stored as a "0". Things don't get much clearer than that.

So--wait, does A5 do all its calculations in floating point?

If true, that's pretty critical info!

[JerryBrightbill]

RE: Checking for empty numeric fields

John

An obvious question I overlooked. If this a numeric field or a character field? If it is a character field just use

alltrim(field) = ""

If the entry can be blank, not 0, I would use a charcter field. You can always use val() later to get a numeric value.

Jerry

[Tom Cone Jr]

RE: Checking for empty numeric fields

Blake,

Actually, in a DBF file, a numeric field is always stored as a series of ASCII characters, not binaries. This preserves the fixed width of the record, and is part of the reason dBase proved so popular when introduced a generation ago.

For field that's numeric, 5 wide, and zero decimals, the number zero would be stored as :

blankspace, blankspace, blankspace, blankspace, 0

or in hex equivalents

20 20 20 20 30


As you probably know,

character type fields are stored as a left justified string of ascii characters, padded on the right with blank spaces to the full field width.

date type fields are stored in character strings, too, using the format YYYYMMDD.

-- tom

[CALocklin]

RE: Checking for empty numeric fields

Am I missing something here or did I bury my response too deep?

The question seems to be, "I want to force the user to enter a number in the 'Kg to Check' field before entering numbers in 'Kg Accepted' and or 'Kg Rejected' fields. But initially all these fields will be blank when the data is input/amended. Only later are these filled."

One way to force this is to not allow the user to enter the 'Kg Accepted' or 'Kg Rejected' fields IF the 'Kg to Check' field is blank.

My original suggest to do this was with a CanArrive event such as:
IF parentform:Check1.text=""
cancel()
END IF

This will work even if the field is numeric because it is only looking at the text in the field object.

(Yes, my original example showed parentform:Check1.text"OK" but, while the concept was correct, parentform:Check1.text="" is more applicable in this case.)

However, an easier option might be to create a Skip rule in field rules using Isblank("Kg_to_check").

[Blake]

RE: Checking for empty numeric fields

Actually, in a DBF file, a numeric field is always stored as a series of ASCII characters, not binaries. This preserves the fixed width of the record, and is part of the reason dBase proved so popular when introduced a generation ago.

Indeed, that's why I put zero in quotes. :-)

dBase traditionally stores everything as characters. But this is my point: the data is literally a "0", not a binary represntation of a zero, so I don't get what Jerry's saying.

In ReXX (a "typeless" language), everything--even variables--is stored as a string. "2" + "2" equals "4". (One sort of amazing thing about that is that you could just about fill up the entire available machine memory with two numbers, and then add them together.)

But I imagine in A5 (and in all xBase dialects), when you take a "2" out of a field and put it into a numeric, it becomes a machine-specific, binary representation of 2.

What it seems like Jerry's saying is that it's not an integer representation (hence, precisely 2), but a floating point representation of a 2 (hence, something like 2.000001).

That sort of shocked me but having written all the above, I realize that xBase doesn't have an integer type, only a floating point numeric, so, yeah, it doesn't do "exactly 2".

But that's not a limitation of the computer, just a simplification on A5's part.

[Tom Cone Jr]

RE: Checking for empty numeric fields

Blake,

Right. I saw the quote marks but didn't get your meaning. -- tom

[David Mason]

RE: Checking for empty numeric fields

Cal,

I agree with you and would go one further and send the focus bak to the field that should not be blank?

Dave

[CALocklin]

RE: Checking for empty numeric fields

That's a good idea. The Cancel() by itself just leaves you wherever you started.

[John Castle]

RE: Checking for empty numeric fields

Many thanks for so many responses! Will go try...