GetField vs. [FieldName]

[emballantine]

This may sound like a dumb question, but...

When writing a script, what would be the difference between using GetField and just using the name of a field? 

ie.

Set Variable [ $$SerialNumber ; Value: GetField (InventoryItems::__pkInventorySerialNumber) ]

vs

Set Variable [$$SerialNumber ; Value: InventoryItems::__pkInventorySerialNumber ]

 

Thanks!

[comment]

You use GetField() when the name of the field is not known in advance and will be only determined at script runtime. For example:

GetField ( Get (ScriptParameter) )

 

[eos]

In your example …

… the field reference InventoryItems::__pkInventorySerialNumber returns the value stored in that field.

… the function GetField ( InventoryItems::__pkInventorySerialNumber ) returns the value of a field whose name is stored in the referenced field (which is most likely not what you intended)

Use GetField() (or Evaluate()) when you pass/store the field of a name as a string and want to evaluate it as a field reference, rather than as a string.

Also note this interplay:

GetField ( GetFieldName ( SomeTable::someField ) )

Edited June 10, 2015 by eos

[emballantine]

So....GetField is only used if you have a field populated by field names? Or looks at a text string stored in a field as a field name?

And GetFieldName passes a field name through as a text string?

Could you possibly give me a situation where you might be passing/storing field names through/in another field? I am just having trouble understanding how GetField would be useful, or a situation where I might use it.

 

Thanks!

 

[Chuck]

I never use GetField, but use Evaluate instead, which reduces to GetField when the parameter passed is just a field name.

The utility of this is somewhat advanced and usually relegated to creating abstracted scripts that perform some function that differs only slightly based on the system state or script parameters sent. But a fairly simple example might be a dynamic sort field in a portal.

One way to build this is to have a global text field that the user can change. Perhaps they can select between "Name" and "Company". Then there's a calculation field that calculates to the contents of the field the user has selected. It might look something like this:

Evaluate (
  Case (
    g_sort = "Name"    ; "Table::name" ;
    g_sort = "Company" ; "Table::company"
  )
 )

If the portal is then sorted by the field that has this calculation, you user's have the ability to change the sort field on the portal dynamically.

To give a more involved example which is a bit too complicated to completely describe, I have a solution I'm working on right now that offers users an edit mode. They click a pencil icon and can then save or cancel edits to the fields that appear. Normally this would require a global field for each of the fields that needs to be available for editing, but I came up with a solution that uses global fields that have layout names of the fields they mirror. A script then uses these names to evaluate the field contents so it can copy the data to the global fields and reverses the process when the edit mode is saved. Using this technique allows the edit mode to exist without almost doubling the number of fields in any table (the entire feature uses a single editing table with a global field for each editable field type, i.e., text, number, date, etc.) and would be impossible to implement without Evaluate or at least GetField.

[emballantine]

Thanks!