Another newbie question. This generated code comes from the Browse States section of the Getting Started lesson.
I understand the convention of Sta:StateName where the table is abbreviated to Sta and then there is a colon and the field name. It makes sense. Similarly I am using loc:localvariable for local variables.
But what is with the double-colon, and why all the other colons in BRW1::View:Browse below?
Similarly, why the :1 in Queue:Browse:1
I did a search in the help for “:” but as usual came up blank. What is the significance of all these extra colons?
! Browse View & Queue for States
Queue:Browse:1 QUEUE !Queue declaration for browse/combo box using ?Browse:1
Sta:State LIKE(Sta:State) !List box control field - type derived from field
Sta:StateName LIKE(Sta:StateName) !List box control field - type derived from field
Mark BYTE !Entrys marked status
ViewPosition STRING(1024) !Entrys view position
Thanks in advance for helping me learn and understand.
As a newbie, do yourself a favor and get in the habit of customizing the object,view, and queue labels to something more meaningful than BRW1::View:Browse. Generated as template defaults, you are free to set these for each control in a procedure using either control properties or the template class tab. For instance, my standard follows an Entity:PrimaryFileName pattern such as:
This is guaranteed to be easier to remember and follow than something with the silly default template instance numbers. (BTW - the templates can also be changed to generate your desired defaults but I would not recommend it until one is a lot more comfortable with Clarion).
In your example of sta:State, there is likely a prefix ,PRE(STA) on something
and within that structure there is a field called state
States FILE,PRE(STA) !, etc
In this case you can write STA:State or you can use dot syntax, States.State
Apart from the prefix notation, the other Colons you’re seeing in labels is just a naming choice.
A colon can be used for any character in a label
other than the first character which must be either a letter or an underscore.
Note: it’s best to avoid adding a prefix to a structure where you can, as it limits the sort of structures you can define. That said, even an empty prefix ,PRE() creates this limitation. What’s worse is structures created in APPs will add an empty prefix.
I’m also of the opinion that using dot notation is clearer, think about this
Sta:ID = 42
was STA for Stations? was it for States?
Stations.ID = 42
One nuance, when working with windows (or reports)
if you have USE(Stations.ID)
The field equate will not be ?Stations.ID rather it will be ?Stations:ID
This is described in HELP[ Field Equate Labels ]
Thanks everyone. I get the idea now. I was also wondering about the short prefixes for table names, and I’ll definitely try to use the notation that Mark suggested.
I use an Access tool that uses a 5-character short code for table names, being the first 3 letters and last 2 letters of the table name, so you get “cuser” for “Customer” and “state” for “State” but “sexex” for “Sex” which is just weird
But in each case you can get name clashes, such as “State”, “Status”, “Standard”, “Statistic” etc for the 3 letter one; and “Customer”, “CustomLetter”, and “CustomerOrder” for the second one.