When using var-> and when referring to the actual object.

[Marcel Kollenaar]

Hi,

I'm still struggling with the var-> prefix. The manual says that you have to use this prefix to indicate that the name that follows is a variable and to distinguish them from other variable groups.

I have several fields (not in a table) on a form and I have named them properly.

parentform:field3handle.value := serversocket.handle
parentform:field4IsBusy.value := serversocket.isbusy

I do not understand when to to use the notation:

parentform:field3handle.value

and when to use the

var->Handle

Can someone explain when to use the two notations?

[G Gabriel]

Re: When using var-> and when referring to the actual object.

Marcel:
This is more like speaking French, a lot of it does not seem to make sense, but there is a reason behind it.

Let me see if I could make some sense here:
1-In v8, the prefix var-> does not seem to make any difference.
2-If you point to a table, then to a field, then you could say:
t=table.open("test")
t.change_begin()
t.field=variable 'assuming you dim'd the variable.
t.change_end()
t.close()
here you do not need to use the hande "value" as it is implied.
On the other hand, if you point to an object (I am assuming you know the difference), then you need to use the handle "value" as the object could have a number of handles. So, in a form for example if you want to set the value of an object you would say:
Object_name.value=variable

3-Field=variable.value does not work because what other handles does the variable have?
I hope that makes some sense.

I didn't do enough testing on this but I think that's the way it is.

[Stan Mathews]

Re: When using var-> and when referring to the actual object.

The use of -> is necessary to distinguish fields, object names, calculated fields, and variables of the same name. If you never use the same name in a given context for more than one of these, you don't have to use ->. If you develop the habit of using -> then you don't need to worry about Alpha mixing up which thing to which you are referring.

The documentation on addressing fairly well explains the use of

:formname:objectname.value
:parentform:objectname.value
objectname.value

and by my reading actually suggests the use of the last syntax.

It would seem that, like the ->, the use of :formname: or :parentform:, is only indicated when one needs to distinguish between things of the same name.

[CALocklin]

Re: When using var-> and when referring to the actual object.

The manual says that you have to use this prefix to indicate that the name that follows is a variable and to distinguish them from other variable groups.

(emphasis added)

I'm not sure where you found that statement or if it's actually a quote but I certainly don't agree with that last part.

Personally, I almost never use the var-> prefix. The only place I've found a need for it is when A5 might have a problem determining if it is a variable name or a field name. It doesn't matter whether they are the same name or not. The issue is that in some places a field name is just a field name (and var-> is needed to identify a variable reference) and in other places a field name will always be preceded with a table pointer (so var-> isn't needed to identify a variable).

To be more precise, the only place I can actually think of where I might use the var-> construction (I'll explain why I don't later) is when passing a filter [or maybe some unusual order expression] to another layout - usually a report but maybe a form or browse that I'm opening. In the case of passing a filter to a layout, the field names are not prefixed with a pointer because the system assumes any name in a filter will be a field name. Therefore, variables must be prefixed with var->. So, in the case of a filter expression, you need to use the var-> construction so it knows that you are refering to a variable name rather than a field name.

[Edit: I just realized this would also apply in expressions returned by other commands like lookups and table.external_record_content_get(). It would be unusual (at least for me) to use variables in these but it would be possible. For example, you might want to return a value from a lookup that is the result of an expression:
lookupc("F", Client_id, "var->Somevar + space(2) + Clnt_namef", "Customers", "Cust_id_" )
I'm not sure why you would do this but it could be done. Again, since the fields (just Clnt_namef in this case) in the return expression do not require a pointer, the variable must be preceded with var-> or the lookup will return an error saying it can't find the field named Somevar.]

Anywhere else in an xbasic script, there is no need for the var-> construction because a field must be referred to by using a pointer to the table or a pointer to an object on the form. This removes any ambiguity. If there is no pointer associated with a name in an xbasic script [except within the quotes used to define a filter for a layout], then it must be a variable. (See below for more about variables as objects on forms.)

Here's an example of how NOT to do it and I think you can see that there is no way for the computer to tell which name is a variable name and which is the field name. (I assume we all know that computers are really stupid and can't deduce much of anything unless we tell them how to do it.)
filter = "Client_type = Ctype"
Oops! Most of you probably guessed that Client_type was the field name. Wrong.

Here's what was intended:
filter = "var->Client_type = Ctype"
Most of us wouldn't normally write it in that sequence but it would work just as well as if the two were reversed. Here's the "normal" way:
filter = "Ctype = var->Client_type"

(Those of you who have paid attention to my other rantings about naming conventions might have guessed that I wouldn't have used Client_type as a field name because it has more than 10 characters.)

Of course, for the above examples to work when passing the filter to a layout, the variable must be global. This 'global' issue is something else that is commonly missed. The report has no idea what the local or shared variables were. So, in this particular case, the only real reason for a global variable is to pass the filter to the report. Since I don't like to create global variables unnecessarily, I prefer to build my filters as follows when they are being done in xbasic. (Most of my filters are done in xbasic rather than embedding them in a layout because that makes the layouts more versatile.)
filter = "Ctype = \"" + Client_type + "\""
or, for those who prefer it:
filter = "Ctype = " + s_quote( Client_type )
Note that in this case the var-> is not needed.
(Actually, I'd use single quotes as long as I knew that the values in the field did not also contain single quotes: filter = "Ctype = '" + Client_type + "'")


All the above really has nothing to do with the parentform:object_name.value method.

The parentform:object_name.value method is used to get a value from an object on a form. That object could be for a variable or a field - it really doesn't matter. So, you might do something like this:
Client_type = parentform:Ctype.value
filter = "Ctype = var->Client_type"

The "var->Client_type" refers to the same variable as "Client_type" but in the context of the filter string we need to make sure the program knows it's refering to a variable and not to a [non-existent] field. And, of course, the variable got it's value from the Ctype object on the parentform.

You didn't ask but here's a warning about using ".value" to GET the value from a form object. Beware when getting the .value of a BLANK field. (SETTING a value with .value works just fine.)

DISCLAIMER: I haven't tested these in v8 yet but they are an issue in earlier versions and I don't yet have any reason to believe they have changed:
- A blank numeric field returns some HUGE number like 1.7*10^23
- I believe the .value of a blank logical field is .T. (could just be an issue with check boxes, I'm not sure)
- I believe a blank date value also returns something strange but I'm not sure about that one.
- The .value of a blank character string is actually blank so this one is OK.


Because of the above, I GET the value of numeric, date, and logical fields as follows:

Numeric field: val( parentform:object_name.text )
This becomes trickier when the field might contain $ signs and/or commas.


Date field: ctod( parentform:object_name.text )
Again, some display formats may cause a problem here.


Logical field: Depends on how it is being displayed on that particular form. Something like this would be typical:
IF left( parentform:object_name.text, 1 ) = "T" .or. left( parentform:object_name.text, 1 ) = "Y"
result_variable = .T.
ELSE
result_variable = .F.
END IF


The other solution would be to get the values from a table pointer derived either with:
tp = table.get("table_name")
or
tp = parentform:tables:table_name.this

[CALocklin]

Re: When using var-> and when referring to the actual object.

I just found another post where Selwyn added more comments about building filters with global variables: http://msgboard.alphasoftware.com/al...ad.php?t=66171

[Marcel Kollenaar]

Re: When using var-> and when referring to the actual object.

Thank you Guys. I got much more information I'd expected and it took some time to read it.

@Gabriel
Thanks for info for use with tables.

@Call
Thanks for the clear detailed info. About the quote: I did a search on the help with "var-> group" to look for information. Then I got the information about "-> (Parent Child Relationship)". Here I found the sentence: "When referencing a field created in the context of a table or layout, you refer to it with the prefix var->, indicating that it is a member of the group of variables." and indeed this is not the same as "The manual says that you have to use this prefix to indicate that the name that follows is a variable and to distinguish them from other variable groups."

@Stan
Very helpful info particular the incomplete addressing style. Besides portable, I think it is also faster. It refreshed my mind again in this case.

--------- Added --------

It solved my "thinking" problem. To be sure I'll use the var-> construction. However from a VBA view I like to reference directly at objects and its properties as in:

result := serversocket.Listen(field1serverPort.value,field2serveripnumber.value)

or

result := serversocket.Listen(parentform:field1serverPort.value,parentform:field2serveripnumber.value)

instead of:

result := serversocket.Listen(var->ServerPort,var->ServerIPnumber)

[CALocklin]

Re: When using var-> and when referring to the actual object.

Beware when getting the .value of a BLANK field.
- I believe the .value of a blank logical field is .T. (could just be an issue with check boxes, I'm not sure)

I just found where I ran into the problem with a logical field. It was in a v7 web app where I was looking up the value of the field using xbasic table mode. (I found an old comment in the .a5w page when working on something else.) Whenever the value was blank it returned .T.

The script was real complicated:
tp = table.open( Session.DataPath + "program_options") '
Session.Skip_fliers = tp.Skip_flyrf
Session.Skip_riders = tp.Skip_rdrf
Session.Skip_ariders = tp.Skip_ardrf
tp.close()

This was raw xbasic embedded in the a5w page just to set some default session values. I found the problem some time ago so it may be fixed now.

I checked just now and this doesn't seem to happen in the desktop version.

[Selwyn Rabins]

Re: When using var-> and when referring to the actual object.

Hi,

I'm still struggling with the var-> prefix. The manual says that you have to use this prefix to indicate that the name that follows is a variable and to distinguish them from other variable groups.

I have several fields (not in a table) on a form and I have named them properly.

parentform:field3handle.value := serversocket.handle
parentform:field4IsBusy.value := serversocket.isbusy

I do not understand when to to use the notation:

parentform:field3handle.value

and when to use the

var->Handle

Can someone explain when to use the two notations?

Marcel

Here is how I like to think of it.

A form has a bunch of objects on it that display field values from the tables on which the form is based, or variable values.

In your Xbasic code, you can either read the '.value' property of any object o the form, or your can reference the field or variable directly. Either technique should give you the same answer (but may not - see explanation later).

So for example, say you have a form that is based on a table which has two fields: 'firstname' and 'age'. Say also that the form has one local variable (called varLocal1), and one shared (i.e. session ) variable (called varSession1)

Say that the textbox that displays the 'firstname' field has an object name of 'objFirstname' (by default, a5 will assign an object name of Firstname, but for clarity here, I will change the object name).

You can reference the value of 'firstname' is these ways:

objFirstname.text --- >> this will return the text shown in the control (after a5 has applied any formatting settings - so if the formatting was Upper then this might return 'MARCEL')

objFirstname.value ---> this will return the raw value of the field that this control is bound to - (without any formatting) - e.g. "Marcel"

t = table.current()
t.firstname ---> this will return the value of the field - which will be same as objFirstname.value.

However, say that your script did this

t = table.current()
t.change_begin()
t.firstname = "Selwyn"
t.change_end(.t.)

now, t.firstname ---> 'selwyn'

but

objFirstname.value ---> 'marcel'

the reason for the discrepancy is the the form has not been resynched to the table.

if your xbasic then does

topparent.resynch()


then,

objFirstname.value ---> 'Selwyn'


Now say that your variables varLocal1 and varSession1 were initialized to 'myLocalvar' and 'mySessionvar'

your xbasic code can read these values in several ways.

1. you can just reference the variable name directy

e.g.

ui_msg_box("","Hello: " + myLocalvar)


If you are writing an expression for a calculated field, that is the ONLY time you need to use the Var-> prefix.

so, if you define a calc field, you would write

mycalcfield = firstname + var->myLocalvar

In Xbasic code you NEVER need to use the Var prefix.

You can also read the value in the control that is BOUND to myLocalVar (or mySessionVar) (if there is one - there does not have to be a control that is bound to any of these variables).

so, assuming that the control that is bound to 'myLocalVar' is called 'objVar1' then

objVar1.value ----> value in varLocal1


You can also get a pointer the local, shared or global variable frame in the form.
so, the following xbasic can be used

pv = topparent.variables("Local")
pv.varLocal1

ps = topparent.variables("session")
ps.varSession1



Hopefully I have not cofused you futher.

In think in summary one can say:

1. You only need to use var-> in the definition of a calculated field. Never in Xbasic code.

2. When you read an object's .value property you are getting the value that is currently displayed in that object on the form (but there is a possibility that this might not be the right value - if a .resynch() has not been done).

[jkletrovets]

Re: When using var-> and when referring to the actual object.

Selwyn, thanks for presenting such a concise and easy to follow explanation.

Regards,

Jeff

[Marcel Kollenaar]

Re: When using var-> and when referring to the actual object.

Thanks Selwyn you made it clear to me.

But maybe it is worth to understand why I was confused. Most of the time I program in VBA and when I need a var to a field I create it when I need it.

In Alpha Five I am forced to choose a variable or define a variable for the table, var or system group when I draw a type-in field on a form. If I cancel this part no type-in field is drawn. So there is a certain need for Alpha to connect the type-in field object I draw to a variable. I can understand to have a kind of pick or define list for the table or system but for the form, I find it odd. And there started my confusion.

After that I started reading the help and came along the "->Parent Child Relationship". In the description is told: "When referencing a field created in the context of a table or layout, you refer to it with the prefix var->, indicating that it is a member of the group of variables." and the confusion was complete.

But now I keep your summary in mind: :)

In think in summary one can say:

1. You only need to use var-> in the definition of a calculated field. Never in Xbasic code.

2. When you read an object's .value property you are getting the value that is currently displayed in that object on the form (but there is a possibility that this might not be the right value - if a .resynch() has not been done).

[Selwyn Rabins]

Re: When using var-> and when referring to the actual object.

Thanks Selwyn you made it clear to me.

But maybe it is worth to understand why I was confused. Most of the time I program in VBA and when I need a var to a field I create it when I need it.

In Alpha Five I am forced to choose a variable or define a variable for the table, var or system group when I draw a type-in field on a form. If I cancel this part no type-in field is drawn. So there is a certain need for Alpha to connect the type-in field object I draw to a variable. I can understand to have a kind of pick or define list for the table or system but for the form, I find it odd. And there started my confusion.

After that I started reading the help and came along the "->Parent Child Relationship". In the description is told: "When referencing a field created in the context of a table or layout, you refer to it with the prefix var->, indicating that it is a member of the group of variables." and the confusion was complete.

But now I keep your summary in mind: :)

You can dim variables for a form WITHOUT having to have any control on the form that is bound to that variable. Just click the V button on the toolbar.
It lets you dim layout, session and global variables. Once you have dimmed variables here, they will show up in the drag drop list.