AxGroup
The AxGroup control contains the bound fields collection that displays the record information. You add AxGroup controls as descendents of AxSection controls. Typically, the immediate child of an AxSection control is a table control or an HTML table with AxGroup controls within the table cells. Figure 3 shows a sample task page in Enterprise Portal.
Following are some high-level control hierarchies for different form layouts.
Here is a form with a list of fields that are displayed one below the other.
<AxForm>
<AxGroup><Fields>BoundFields or TemplateFields...</Fields> </AxGroup>
</AxForm>
|
This form has two expandable sections, with fields displayed one below the other.
<AxForm>
<AxMultiSection>
<AxSection>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AxGroup>
</AxSection>
<AxSection>
<AxGroup><Fields>BoundFields or TemplateFields...</Fields> </AxGroup>
<AxGroup><Fields>BoundFields or TemplateFields...</Fields> </AxGroup>
</AxSection>
</AxMultiSection>
</AxForm>
|
The following form has
two expandable sections, with fields displayed one below the other. In
the second section, the groups are displayed in two columns.
<AxForm >
<AXMultiSection>
<AxSection>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AXGroup>
</AXSection> <AxSection>
<table>
<tr><td>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AXGroup>
</td><td>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AXGroup>
</td></tr>
</table>
</AXSection>
</AxMultiSection>
</AxForm>
|
Here is a wizard with two steps.
<AxForm>
<asp:Wizard>
<asp:WizardSteps>
<asp:WizardStep>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AXGroup>
</asp:WizardStep>
<asp:WizardStep>
<AXGroup><Fields>BoundFields or TemplateFields...</Fields> </AXGroup>
</asp:WizardStep>
</asp:WizardSteps>
</asp:Wizard>
</AxForm>
|
AxLookup
AxLookup is
used in data entry pages to help the user pick a valid value for a field
that references keys from other tables. In Enterprise Portal, lookups
are metadata driven by default and are automatically enabled for fields
based on the relationship defined in metadata in the AOT. An example is
the customer group lookup on the customer creation page. The extended
data type (EDT) and table relationship metadata in the AOT define a
relationship between the customer table and the customer group table, so
a lookup is rendered to pick a customer group on the customer group
field when creating a customer record. You don’t need to write any code
to enable this behavior—it happens automatically.
In some application scenarios, however, the
automatic behavior isn’t sufficient, and you might be required to
customize the lookup. The lookup infrastructure of Enterprise Portal is
designed to offer flexibility and customization options in both X++ and
in C# for developers to tailor the lookup user interface and the data
retrieval logic to their needs.
In the AOT Data Set node, you can override the dataSetLookup
method of the field in the data source to control the lookup behavior.
For example, if you want to filter the values displayed for a zip code
field based on what has been entered for a country, state, or county,
you override dataSetLookup, as shown in the following code.
void dataSetLookup(SysDataSetLookup sysDataSetLookup)
{
;
if (custTable.CountryRegionId)
sysDataSetLookup.parmQuery().dataSourceNo(1).addRange(
fieldnum(AddressZipCode,CountryRegionId)).value(queryValue(
custTable.CountryRegionId));
if (custTable.State)
sysDataSetLookup.parmQuery().dataSourceNo(1).addRange(
fieldnum(AddressZipCode,State)).value(queryValue(custTable.State));
if (custTable.County)
sysDataSetLookup.parmQuery().dataSourceNo(1).addRange(
fieldnum(AddressZipCode,County)).value(queryValue(custTable.County));
}
|
In the preceding example, addRange
is used to restrict the value. For some scenarios, you might want to
build the entire list dynamically. In that case, you can override the dataSetLookup method and build the entire query yourself.
...
...
Query query;
List _list;
_list = new List(Types::String);
query = new Query();
query.addDataSource(tablenum(ReturnReasonCode));
_list.addEnd(fieldstr(ReturnReasonCode,ReasonCodeId));
_list.addEnd(fieldstr(ReturnReasonCode,ReasonCodeGroupId));
_list.addEnd(fieldstr(ReturnReasonCode,Description));
sysDataSetLookup.parmLookupFields(_list);
sysDataSetLookup.parmQuery(query);
...
...
|
SysDataSetLookup in X++ provides many properties and methods to control the behavior of the lookup.
You can also customize the lookup in C# in the Web User Control by writing code in the Lookup event of bound fields or by using the AxLookup control for fields that don’t have data binding. To use AxLookup to provide lookup values for any ASP.NET control that isn’t data bound, you should set the TargetControlID property of the AxLookup to the ASP.NET control. You can base AxLookup on the EDT, the data set, the custom data set, or the custom User Control by specifying the LookupType
property. You can also control what fields are displayed in the lookup
and which one is a select field, either through the markup or through
code. You can write code to override the Lookup event and control the lookup behavior, as shown in the following code.
protected void AxLookup1_Lookup(object sender, AxLookupEventArgs e)
{
AxLookup lookup = (AxLookup)sender;
// Specify the lookup fields
lookup.Fields.Add(AxBoundFieldFactory.Create(this.AxSession, lookup.
LookupDataSetViewMetadata.ViewFields["CustGroup"]));
lookup.Fields.Add(AxBoundFieldFactory.Create(this.AxSession, lookup.
LookupDataSetViewMetadata.ViewFields["Name"]));
}
|