-->

Lookups and drop downs in AX - Part I

maqk® by MAQ Khan | 9:49 PM

Lookups are pretty straight forward, drop the related field and AX should bring a nice drop down to you. However things can get pretty nasty when you apply further behaviour, the simple drop down remains no simple.

As i just wrote the one liner, drop the field and there u go. However there are other methods to achieve better results as well.

Depending on the join, the behaviour and display of the lookup depends. A RecId based master child relation field will drop the RecId of the master record. Se below;


The objects I have used to achieve the above are;

  • 2 tables named master and child. 
  • Joined child table with master as a 1 to many relations
  • Created a new form (no template), added both tables in the data sources. 
  • Dropped the relation field on the form.

Thats it, but the result is pretty rough, not helpful to the UI at all, what does that 10 digit typical surrogate means to the end user, its a nightmare for him. The good thing is, there is no nightmare for the devs :D

What MorphX has done is place an integer field on the form bind to the child data source's master table relation field. The existing relation provides the lookup behaviour automatically, no code to override, no nothing, pretty straight forward.

AX is a great RAD platform, it does not give u time to do all the coding for these small repeating things, its already there, u need to know how :D

Well the most usual practice a dev has is to copy an existing behaviour, that will do the job, but I actually went a little deeper into it and played with all the relevant features available. Lets dive in then.

The Table's Autolookup group

There exist a default group for each table, 'Autolookup', lets drop a field into it and see the difference if any;
To achieve this, i placed a data field (any field u can choose) in the Autolookup group of the master table. We have edited the master table for the simple reason that the drop down or lookup is supposed to fill from there :D



The result of this is;

As you can see, the code field has started appearing next to the unwanted RecId. This is at least a little better than the first pure raw result. Of course we still need to remove the unwanted id, but what we learned from this step is that fields present in Autolookup group of a table starts appearing in lookups belonging to that table.

Lets add another field to ensure what we learn is exactly what we just described :D adding 1 more field results in following;

Hence ensured. This means we need to fill the Autolookup group for every setup / master table so that a decent user friendly lookup appears whenever a reference is made to them.

But the unwanted rec id is still bothering, and also 1 more thing is the behaviour of the form when a particular value is selected; see below;


After a selection is made, the same rec id is appearing about which, the user have no hint what has it actually selected.

Lets see if adding an Index have an effect on this. An index is basically created on a table on fields so that searching gets fast. But it is also used as a means to achieve uniqueness on a particular set of fields.

Adding an index on a third filed has no effect on the lookup (no new image required :D)
However, removing each field from Autolookup group with an index on a third field (which was never part of the Autolookup group) brings the following result;


This means that field(s) present in Index(es) appears in the lookup of that table. However, fields in Autolookup group overrides them. We are finding core facts here, no theories, and I really enjoy this :D

The unwanted RecId is still appearing, lets see what another default group AutoIdentification has to do with it

The AutoIdentification group
By default, you can never add any field in this group by dragging your custom selection. The only way to add a field into it is to create an index.

Adding a simple, non unique default index does nothing to the AutoIdentification group, we will need this index set as a replacement key. To do this, the index must be unique (set allow duplicates to No in the property sheet) and select this unique alternate key index as the replacement key for the desired master table. There you go, you got the index field in the AutoIdentification group :D, illustration for you for precise guidance :D



This brings the indexed field 'code' in the AutoIdentification group.

But how will it effect our lookup ? Well the answer is, now AX knows your master child relationship more better, so Drag the same field once again, and to your surprise, this time it wont be a simple integer field bind to the child table, its a whole new 'Reference group' control.


Now we have 2 lookups on the form actually, the one with the previous incomplete table configuration (integer field bind to child table's master referencing field) and the new Reference group with more properties to explore :D

This has get us rid of the unwanted RecId, now we have quite a decent lookup appearing at our screen. The user will be delighted to see this as compared to the previous ones. And as we have already learned, adding more fields in a lookup can make lookups more detailed if required.

Scenario: Show more fields in lookup but select specific
Yes, how can we achieve this? That is, show some filed in the lookup , but when selected, a different field gets selected in the textbox area. What I am trying  to say is a typical code description scenario in which user opens a lookup that shows code and descriptions both, but  once a selection is made, only code is selected. How to achieve that ? Well again as so many times you have read that AX is fast RAD platform, nothing takes long time here. To achieve our this goal, we need to look at some of the properties on the reference group control.

Reference group control - Details
The key properties of this control are as follows;

  • ReferenceField: A reference field on the bound data source to use as the physical binding. This field is not displayed to the user
    In short, this is the field which will be used behind the scenes and the record will be populated with this value. In our example, the reference field is the 'master' field in the child table, the rec id of the master table's record the user selected in the drop down.
  • ReferenceFieldGroup: A field group on the primary key table to use as the logical binding. These fields are displayed to the user.
    In our example, the group selected is the AutoIdentification group, which was populated when we created a unique index, used it as alternate key and set it as master table's replacement key.
Other fields of course contains data source and data field, whenever dropping a lookup form master table, drag the field from the child table, not the master table since the changes are to be made in child table no the master one :D

Now to have multiple values displayed when lookup is opened and select one of them in the drop down, we will do the following

add multiple as many fields you want to display to the user when lookup is opened, we will add code and descr fields. And already in the AutoIdentification group, we have the code field ( the indexed field), so this will bring us the desired results. The following is the table level filed group configuration and then its result:



This is the way to do the simple lookups in AX. To conclude all this, i have written concluding points below. For more advance topic, I will write the Part II tomorrow إن شاء الله‎ 

Conclusion:

1.) Autolookup overrides index
2.) Fields from each index are fetched in lookups along with PK (RecId) when no field exists in autolookup group of primary table.
3.) When multiple indexes used on table ( & no field in autolookup), first field of each index is brought, depends on their order in index.
4.) Use Reference group control for better user friendly lookups. Reference group provides two properties 'ReferenceField' and 'ReferenceFieldGroup' which fetch relevant data in the lookups as required by the user



top