·
An extended data type is extended from a
base type or another extended data type. The difference is that an extended
data type has a property sheet where information such as labels, length and
left or right adjustment are stored.
·
EDT are a central part of MorphX. Whether
you are adding fields to a table or declaring variables from X++, extended data
types should always be used instead of using base types and the reason for that
is Dynamics Ax provides powerful features to handle EDTs.
·
The best practice is to check before
creating a new extended data type you should check whether in existing one will
fulfill your needs.
·
If you have found an EDT which suits your
needs, but another label or help text is required, you should create a new EDT
with your requirements, but never modify existing EDT accordingly because this
will impact the fields which are already using it.
·
Some EDTs are extended from system extended
types (under AOT/System Documentation/Types. Regional settings like amount and types for system fields are
all created as system fields.
Example(1)
: Steps to create EDT for replacement of standard AccountNum EDT.
1. Go to the node Extended
Data Types, right-click and create a new string. Name
the new extended data type "DataDic_AltCustAccount" using the
property sheet.
2. Enter the label "Alt. customer" and the help text
"Identification for alternative customer account." for the new
extended data type.
3. Extend DataDic_AltCustAccount from AccountNum using the property
Extends.
4. Expand the nodes for DataDic_AltCustAccount and go to the node Relations. Add a new
relation by right-clicking, choose New
and select Normal. Use the property
sheet to select MyFirstTable and the field accountNum as the relation.
5. Save the extended data type and wait until the database has been
synchronized.
6. Go to the table CustTable and locate the field
altCustAccountNum. Open the property sheet and change the ExtendedDataType property to DataDict_AltCustAccount.
7. Locate the relations in CustTable and find the relation MyFirstTable.
Press the delete key to remove the relation for MyFirstTable.
8. Save CustTable.
9. Change the extended data type for field accountNum in MyFirstTable
as done at step 6 and save MyFirstTable.
Now we
have a new EDT for the alternative customer account. The table relation which we
deleted in CustTable was unnecessary as the EDT just created will now handle
that relation.
It is much more flexible having the relations at the EDT level as you will not have to modify each table where the extended data type is to be used. The EDT was also changed for the field accountNum in MyFirstTable and now no lookup button will be added to accountNum as the related table is the same.
It is much more flexible having the relations at the EDT level as you will not have to modify each table where the extended data type is to be used. The EDT was also changed for the field accountNum in MyFirstTable and now no lookup button will be added to accountNum as the related table is the same.
Note:
Both EDT and base enums can be used as extension for a field. So why to create an EDT for a base enum? This is because, Only EDTs can be used when adding a field to dialog. If a field used in a dialog is of the type enum like NoYes, even then the extended data type NoYesId extending the base enum NoYes must be used.
Extended Data Type Array:
- Another powerful feature of EDTs is an
EDT can also be defined as an array. And each array element of the EDT
will be created a database field.
- The node Array Elements is
used when defining an EDT as an array. The first entry of the array will
be the entry created when creating a standard EDT. And then array entries
are created under the node Array
Elements.
- Only label and help text is specified
for these subsequent array entries. All other properties are inherited
from the first entry in the array. As with the first entry, separate
relations can be defined for each array entry.
static void DataDic_EDTArray(Args _args)
{
CustTable custTable;
;
select firstonly custTable;
info(strfmt("%1, %2, %3",
custTable.dimension[1], custTable.dimension[2], custTable.dimension[3]));
}
Output:
The
same notification for declaring a variable is used when addressing the single
array entries of an extended data type. In the example above, the 3 dimensions
from CustTable are printed for the first record. When looking up the fields for
CustTable, only the field Dimension will be listed for the array.
You must manually specify the array entry to be printed. If array entries are referred directly, such as in this example, a new array entry added will not be printed. A better solution would have been to loop all array entries rather than fix the code to print the first 3 entries.
You must manually specify the array entry to be printed. If array entries are referred directly, such as in this example, a new array entry added will not be printed. A better solution would have been to loop all array entries rather than fix the code to print the first 3 entries.
If
looking at a data source in a query, the opposite will be shown. A data source
will show a field for each array entry. Dimension is always added to a field
group when used in forms and reports so the dimension field group will
automatically recognize a new array entry added.
1 comment:
Sir,
Your post is very help full. if you kindly discuss about look up with the help of extended data type and other static method then it will be very help full.
Thanks in advance.
Piku.
Post a Comment