Recently I had to change the list of available fields in a DropDown box on a page. As you might already know, a DropDown is a result of a field having a TableRelation.
For example, on a Sales Order page there’s a field “Sell to Customer No.“. This field has a table-relation towards the Customer table and as a result of that on the page there’s a DropDown button displayed in it’s textbox.
This is the case for every TableRelation, but by default only 2 columns are displayed in the DropDown. (the Pk and Description or Name). To add extra the columns you have to design the table to which there’s a relation, in this case the Customer table, and open its fieldgroups:
There you make an antry and give it the name: “DropDown“. (Be sure to type it exactly otherwise it won’t work :)) In the Group field you can enter the fields to be shown in the dropdown. This feature is also called the new “Find As You Type“, because depending of the column you select in the dropdown, you can start typing and it will work like the good old “Find As You Type” as we know from the Classic Client.
To facilitate order entry for the key user they might request you to add extra fields in these dropdowns. So if you would add the Salesperson Code, it will appear in the DropDown. So far so good, so far nothing new …
But the problem is that sometimes the newly added fields are not “clickable”. They appear in the dropdown, but the “Find As You Type” functionality is disabled, as shown here:
This had me confused a little bit, because I was trying it using a view instead of a ‘normal’ table, and I thought I had forgotten something in Sql Server. But then I checked and the problem also occurs for other tables.
Why is this and can this be “enabled”?
Well, how to enable it is simply by making sure that there’s a Key for the field you added in the DropDown. So in this example, there should be a key in the customer table containing the “Salesperson Code“. So if you add a Key to the Customer table the result is this:
Now we can select the column in the DropDown.
It seems obvious, coming from the Classic Client, but the Role Tailored Client always runs on SQL Server, so I wonder what’s the advantage of doing it like this (using a Key)? Because even when you set the Key property MaintainSQLIndex to No, it still works fine 🙂
And I’ve also tested this with a view (see next blog post about using SQL Views in NAV 2009).