Accessing field / variable values on a form

[enstorms]

I've only been working with a5 for a couple of months now. Don't know if I'm getting into a bad habit or not, so would like some input on how you experienced a5 guys do this. I have found the easiest way to get values when writing code in xbasic, is to have a field on a form (hidden if it doesn't need to be seen) that I can reference with either the form pointer or just the field object name itself. But I end up with my form window looking like it has post-it notes all over it when in design mode. This seems much easier, though, than using a table pointer and mix and matching form objects with table field objects.
Any suggestions would be greatly appreciated.
Thanks.
Ernie

[Al Buchholz]

Re: Accessing field / variable values on a form

set the hide property for the objects that you really don't want to show..

[enstorms]

Re: Accessing field / variable values on a form

Hi, Al,
Well, that's what I'm saying. I usually have several all over the limited real estate that I have hidden.

have a field on a form (hidden if it doesn't need to be seen)

So in design mode it looks like post-it notes all over the form. Was just wondering if this is the norm, or if there was a better way of programming. Sometimes the easiest road isn't always the best down the road.
Thanks for your input.
Ernie

[Al Buchholz]

Re: Accessing field / variable values on a form

Sorry I missed your reference to hidden...

So put them on top of each other in a free area of the form, make them small, and use the object explorer to find them if needed.

[CALocklin]

Re: Accessing field / variable values on a form

If I don't need the field on the form for the user to see, I use a table pointer in the xbasic code. Of course, I write virtually everything in xbasic so I don't know how this would apply if you were using action scripting.

However, I do NOT recommend using Table.Open() to get the pointer because that requires you to also find the correct record. Either use <tbl_pointer> = Table.Get("<tablename>") then use that pointer to get all the field values you need or, if only one value is needed I prefer parentform:tables:<tablename>.<field_name> because it's all in one line.

Note that getting the value from the table with parentform:tables:<tablename>.<field_name> is nearly the same as getting it from the form with parentform:<object_name>.text

You will note that I don't use parentform:<object_name>.value. This was not a typo. Using the parentform:<object_name>.value method sometimes gives strange results. I'm not sure exactly what is happening in v8 and v9 since I quit using this method a long time ago. ("Once burned" and all that.) In previous versions you will get errors such as:
- A blank numeric field will return some huge number like 10*10^123 - not zero like you might expect. (Don't quote me on that "123" number.) If you get the .text result then you can check if it is blank. I suppose you could also check to see if the value is > 10*10^99 to determine if it was supposed to be blank. After all most people don't use numbers higher than 1 with 99 zeros on the end. Of course, if you get the text result then you also have to be concerned with non-numeric characters in the text string.
- A blank logical value sometimes results in "True". I know I've seen this but I'm not sure if it was only for a few builds or was true in all builds of certain versions.

Due to having past issues with things like this, I no longer use .value to GET data from field objects but I do use .value to put data into field objects. My preferred method now for getting data is the "table pointer" via parentform:tables:<tablename>.<field_name>.

You can also use Table.current() if it is a one-table form or you want to just use the parent table of the set.

The Table.current() command also works for child tables in a set but I don't like to use it that way because (a) it's more difficult to find the correct slot number of the child table and (b) sometimes I've changed set structure and then the number of the appropriate child table changes. The big problem with "b" is that I probably won't remember that my script(s) contained references to that child table by slot number until a customer gets an error message. Of course, if the set only contains one child table then this probably won't be an issue.

[enstorms]

Re: Accessing field / variable values on a form

Al & Cal,
Thanks for the responses. Got good info from both of you. One re-affirms I'm not too far up the wrong tree. Cal, thanks for the info on how you get data. Found your experiences using the .value very interesting. I have had, in my limited experience with a5 some inconsistencies in data retrieval using the form pointer methods. Posted about a week ago about this issue, not knowing when or if I needed to use the .value or the .text or neither. Things are improving, but still have my frustrating moments. Seems just shutting down or compacting the db helps most of the time. I'll continue my education in this area. Thanks again for the help in understanding.
Ernie

[MoGrace]

Re: Accessing field / variable values on a form

Hi Ernie,
One advantage to hiding certain key fields on the form is that during design you can unhide them to see what is happening. If I have a conditional object on the form I hide them in the default page which I intend to never show. It is also an easy way to reference a field in a browse by putting it outside the browse on the form. I think it is a good thing for beginners to start at the beginning - though some of us never progress much past that ;).

[enstorms]

Re: Accessing field / variable values on a form

Thanks for the input, Robin. Yes, that is why I haven't chosen yet to make them small and on top of each other yet. I like to unhide them to see what's going on when my code starts screwing things up. Hadn't thought about adding a browse field onto the form for reference. Always thought it had to be in the browse and then reference the column. Thanks for that idea.
Ernie