Field Lookup value on Form

[enstorms]

As with most, I think, I dislike the required field field rule so I code my own when a Save button is pushed. I'm still trying to understand when I need to use val() and when not. (I can't seem to find Selwyn's good article on that.) In the attached app, there is a very simple form, dtlsform, with one field on it, Bank_id. This is a lookup into the bank_accts table. I have discovered a grave misunderstanding on my part. I have always tested the form field value on these type lookups. When I changed my code to val(form field.text), it always seems to return zero. So I suppose I need to be testing table.field. The attached app form has two buttons, one testing the form field value which returns zero, and the other testing the underlying table value which returns the correct value. Is this the way it is supposed to work? I would like some clarification.
Thanks.
Ernie

[Stan Mathews]

Re: Field Lookup value on Form

You have the invent_details bank_id field defined as a lookup storing the bank_id from bank_accts bank_id but displaying the bank_name, I think.

The underlying table field contains the bank_id (1 here for Chase) but the form display text is "Chase". Val("Chase") is 0. Table field content is 1.

[enstorms]

Re: Field Lookup value on Form

Stan,
Thanks for your response. Yes, it was my mistake to think the form field was somehow storing the actual id number and displaying the text/name value. I think I got that idea from a previous programming language. Will have to go through my code and change all this to reference the table values for numeric type fields.
Thanks again.
Ernie

P.S. Now this is screwy.... Just went back in and changed my code on the form value button to read the form field.value instead of the form field.text because I think in debugging this, I was getting that LONG number when the field is zero, (.17900000000000.....). Now it's reading one, just like the table.value. What are you seeing???

[Tom Cone Jr]

Re: Field Lookup value on Form

When you say

vValue = val(parentform:bank_id.text)

You're telling Alpha Five to do the following:

a) Find the object named "bank_id" in the current form.
b) Find the Text property of the "bank_id" object
c) Then pass the TEXT string you just found to the VAL() function.
d) Since the TEXT string you passed to the VAL() function does not begin with a numeric digit, VAL() returns a zero.

working as designed. In this case the "Bank_id" object contains the bank name, while in the underlying table the "Bank_id" field in the table contains the bank id number. The Text property of the Bank_id object in your layout is different from the Value property of the Bank_id object in your layout.

See the attached screen shot created from the Object Explorer

[enstorms]

Re: Field Lookup value on Form

Tom,
So if I wanted to test whether or not the form field had been filled in, I could use:

if isblank("bank_id") then
    do whatever
end if

The particular form I am working with is using conditional objects, so there are about 6 bank_id objects on the form depending on a value in a multistate button. I usually refer to particular objects on the form by their object name, i.e. bank_id0, bank_id1, etc. In the isblank() function, I can use the basic field name, i.e. bank_id????? I guess the isBlank() function is referring to the underlying table field and not the form field.
Ernie

[Stan Mathews]

Re: Field Lookup value on Form

I guess the isBlank() function is referring to the underlying table field and not the form field.

That's the way the function is defined.

Result_Flag as L = ISBLANK( Field_Name as C )

I believe you can use isblank with other types.

if isblank("bank_id.value") then 'bank_id0.value, etc
    do whatever
end if

[enstorms]

Re: Field Lookup value on Form

Stan,
It does work with any field type but also says to use isnull() to test for blank strings. I'm getting a clearer picture of all this, if I can just remember it.
Thanks again for your help.
Ernie

[Stan Mathews]

Re: Field Lookup value on Form

Apparently you can isblank() variables, not sure about form objects. Just a point of interest.

[Tom Cone Jr]

Re: Field Lookup value on Form

Ernie, you are not understanding the concept of object properties.

To extend what I gave you before you would not do this:

if isblank("bank_id") then
    do whatever
end if

You'd do this

if len(alltrim(parentform:bank_id.text)) = 0 then
    do whatever
end if

This tells Alpha Five:

- find the bank_id object in the current form
- find its text property
- trim the text property of all blanks
- examine the length of the trimmed string
- if its zero then do your processing

The code snippet you proposed has nothing to do with what I was showing you about the text and value properties of the object in your form layout.

This is confusing for many people.

Xbasic has commands that permit your script to talk directly to the table beneath your form. It has other commands that permit your script to intereact with the GUI... with the objects in your layout which are displaying field values from the table. These objects are different from the fields in your table. Many people seem to think they're the same thing. I suspect you are making this mistake. The object in your form layout that displays a field value from your table is a completely different (separate) thing than the record buffer in memory that contains the current field value.

Later ...

t = table.current()
my_fld_value = t.my_fld     'uses methods talking directly to the table

my_fld_text_property = parentform:my_fld.text   'uses property of the object

These normally produce the same result. In your case, because you've defined a coded lookup in field rules, the actual table field value is one thing, but the displayed value in the OBJECT in the form is another.

Is this getting clearer?

[enstorms]

Re: Field Lookup value on Form

Thanks, Stan.
Ernie

[enstorms]

Re: Field Lookup value on Form

Tom,
Sorry, your post hadn't appeared when I last responded to Stan. Yes that does make sense. I've been a little hesitant to use table field values while in enter mode. For some reason, I had in the back of my mind they weren't really available until the record had been saved. It is becoming clearer.
However:

if len(alltrim(parentform:bank_id.text)) = 0 then

So if there is no text in the field, alpha may see spaces as not being blank? The ID field is n, 16. Nothing has been selected, but I would still need to trim the nothing? It would not interpret that as being blank?

Ernie

[Tom Cone Jr]

Re: Field Lookup value on Form

So if there is no text in the field, alpha may see spaces as not being blank? The ID field is n, 16. Nothing has been selected, but I would still need to trim the nothing?

No I suppose not. I guess I've been thinking that your data type was CHARACTER. For character data it's difficult to know there's no text in the object. The blank spaces a user enters with the spacebar count as "text", but are invisible. I guess you could make a multi-step sequence in which the script checks the length of the "text" in the text property of the object, and then checks further to see if the text only consists of invisible blank spaces if you want. Your script could then branch if the untrimmed length is zero or if the string only contains "blanks". For me, it's simpler to trim whatever's there and check the length of the trimmed string. Over the years I've seen lots of instances where the user inadvertantly presses the spacebar and inserts a blank space into a field. I've learned the hard way that it's a mistake to assume that there's "real" data in the field simply because the untrimmed length of the text string is greater than zero.

In the case of a numeric field this shouldn't be necessary cause I don't think the user can enter any blanks into such a field in the first place, right?

Good luck with your project.

-- tom

[enstorms]

Re: Field Lookup value on Form

Thanks, Tom. I guess that is why the help file says for character fields, use the isnull() function. Thanks for the tips on what you've learned the hard way. Seems no matter how tight you think you have your code, some user will figure out a way to break it. But that's just part of the process in writing programs.
Thanks again for all your help in my education process.
Ernie