vrijdag 9 april 2010

Form Radiobutton values

Ever wondered where the values in a Form RadioButton come from?
The properties of the Radiobutton AOT-object only show one value.
Where's the rest?

As an example, I'm using the DEV_SysTableBrowser, which can be found on Axaptapedia.

The AOT of that project - folded out to the radiobutton - looks like this:

When we run the form, it looks like this:

The radiobutton is grouped in the "Show fields" group, and has 3 values:
  • All fields
  • Field group
  • User setup
The properties of that radiobutton are:

So, we know that there are 3 items, and that item 1 has the value (Text) "All fields".
But where are the other 2 values?
Actually, they are also there, and here's how to reveal them:

Step 1: Select the Item property

Step 2: Enter the number of the item for which you want to see or set the value

Step 3: Tab out of the Item property

Notice that the Text property still says "All fields" (Item 1), while we have indicated that we want to see Item 2.
This is due to a refresh issue.
The Text doesn't get refreshed when the Item property changes.
We'll have to do the refresh ourselves.

Step 4: Select the Text property

Step 5: Tab out of the Text property

And there you have the value of the second item :)

These values are actually stored in an array.
This is the part of the .XPO file that defines this RadioButton.
See the highlighted part.

donderdag 8 april 2010

Lookups / Lookup Form

Lookups can be defined on the EDT, property "FormHelp".
see http://www.axaptapedia.com/index.php/Lookup_Form

Else, there can be an automatic or a manual lookup.
see http://www.axaptapedia.com/Lookups

Write your own lookup (override lookup method)
This is an example of an ItemId lookup:
public void lookup()
    SysTableLookup        sysTableLookup = SysTableLookup::newParameters(tablenum(InventTable), this);
    Query                 query = new Query();
    QueryBuildDataSource  dataSource = query.addDataSource(tablenum(InventTable));
    QueryBuildRange       range = dataSource.addRange(fieldnum(InventTable, ADUSawingItemId));

    sysTableLookup.addLookupfield(fieldnum(InventTable, ItemId));
    sysTableLookup.addLookupfield(fieldnum(InventTable, ItemName));

Adding custom labels to the dropdown fields
After you add the field, you add the custom label:
public void lookup()
    SysTableLookup        sysTableLookup = SysTableLookup::newParameters(tablenum(ConfigTable), this);
    Query                 query = new Query();
    QueryBuildDataSource  dataSource = query.addDataSource(tablenum(ConfigTable));
    QueryBuildRange       range = dataSource.addRange(fieldnum(ConfigTable, ItemId));

    sysTableLookup.addLookupfield(fieldnum(ConfigTable, ConfigId));
    sysTableLookup.setLabel("Field ConfigId");
    sysTableLookup.addLookupfield(fieldnum(ConfigTable, Name));
    sysTableLookup.setLabel("Field Name");


Filtering CongfigId lookup
I encountered a situation where I had a form with
- an unbound StringEdit control of ExtendedDataType ItemId
- an unbound StringEdit control of ExtnededDataType ConfigId
The dropdown on the ConfigId seemed to always be filtered in such a way
that it always showed only the ConfigId's for the ItemId in the ItemId field.
After some debugging, I found out that it was because I had a method called itemId on my form.
Apparently, in the ConfigIdLookup form, the executeQuery of the ConfigTable datasource says:
void executeQuery()
    QueryBuildDataSource    qbds = this.query().dataSourceTable(tablenum(ConfigTable));
    fieldId                 fieldId;

    fieldId = inventDimFormSetup.callerItemFieldId();
    if (fieldId)


and inventDimFormSetup.callerItemId() is
ItemId callerItemId()
    if (! callerHasItemId)
        return '';

    if (callerItemIdMethod)
        return callingElement.args().caller().itemId();
        return this.callerItemIdFormDatasource().cursor().(this.callerItemFieldId());

So, the ConfigIdLookup form effectively called my itemId method to filter it's ConfigTable datasource!