When looking through Axapta code you will see a lot of references to the type Args. This type is used as a general method for sharing construction parameters. It works well because in the Axapta
- the typical number of parameters is small
- the types of parameters used is very similar
- construction of the main objects often entails constructing multiple collaborating objects that need access to the same shared constructor arguments.
In traditional OO code each object will have one or more constructors. These constructors would have different numbers of arguments and types, as required. For example, a class representing a form might have a default constructor that would simply show all the items in the table. It could also have a constructor that accepted a string that was used to highlight the row with a matching primary key, newSelect(str key). Or one that filtered all the values to match the provided range, newMinMax(str smin, str smax). Side note: in Axapta there is no overloading, we accomplish the same thing with multiple static constructor methods. They are typically named newXyz, newAbc, etc. Sometimes the create prefix is used, for example createXyz, createAbc.
This works well in the simple case, however if a class needs to construct many collaborating objects each requiring the same specialized constructors, the process becomes unwieldy. In addition, the construction is often handled
This transforms the traditional OO multiple constructors (like this)
Into the he Axapta Args constructor pattern, which would look like this:
The work is simply moved for a multiple static constructors to multiple if-else blocks. Note that most forms and reports do the work in the init() method instead of an overloaded new. The effect is the same. When you consider that many forms/reports have at least one helper class (often with the same name) and the sub‑elements (sections, queries, controls) that may also need to modify their behavior based on the startup parameters you can see that passing a single Args around is much easier. You don’t even have to pass the Args around if the object inherits from ObjectRun (which all forms and reports do), since ObjectRun holds the initial constructor Args. The pattern would
Classes and jobs also use the Args pattern. Classes that are the target of an Action menu item will have a static main method that accepts a single Args parameter. By default jobs will also receive a single Args parameter.
Generic Args Properties:
A reference to the object that created the Args.
The table that lookupField and record refer too. However, this is often left null since the proper dataset is implied.
Which of the designs within a report should be used, null implies the default design.
When showing a form, the field to filter on.
When showing a form, the value to filter with.
The name of the menu item that caused the object to be created.
The type of the menu item that caused the object to be created.
For reports and forms this is the name of menu item that invoked the form/report
I have only seen this used internally in the kernel to insure dialogs child windows are properly nested.
A generic string property.
One of the values from the base enum specified by parmEnumType. Works together with the parmEnumType to select different behaviors.
The id of the base enum. Typically you would use the enumnum(some-type) function.
A generic object property.
A blank record for dataset. You can create a blank record with the DictTable. makeRecord() method. Often the lookupField is filled in with the lookupValue.
An interesting example on using Args to launch a form/report is in the \Classes\ClassFactory\drillDown method.
An example of a form taking different actions based on the enumeration parameter can be seen in the PriceDiscGroup form:
An example of a class preparing some enumeration args for a form to consume can be found in the ProdJournalCreateBOM class: