KTA: Populating Drop-Downs on Forms

Drop-Down controls allow your users to select a single item from a list. As there are different methods of populating said lists, this article tries to shed some light on which method is more suitable for different use cases. Use cases, you say? It’s just a list of items, you say? Sure, that is true. But let’s analyze which kinds of items we may be facing, first:

  • Static content: your lists could consist of static items, i.e. entries that do not change over time. A good example is the selection of either ‘yes’ or ‘no’: it’s unlikely that this list will ever change.
  • Dynamic content: your lists hold content that changes over time. Change can happen slower or faster. In addition, any data originating from an external system falls into this category, as well. Data from a web service represents (potentially) fast changing content, data from your ERP system such as your branch offices by name represent slower changing items.

Based on the type of items in these lists, one method or the other is more suitable. The following paragraphs describe them in detail.

Static content

As laid out earlier, static content is unlikely to change over time. Still if it does, change happens infrequently. There are two methods to handle static content in KTA. Let’s start with the one that seems to be the most logical choice at first, and then switch to the other one. The better one. And yes, I will explain why I dislike the first one.

Static items in the drop-down properties

Ah, the quick-and-dirty method. In the extended properties of the drop-down itself, on the data tab, static values can be defined. A default value is possible, as well. While easy to set up, I do not like this approach: there is no clear separation of the view (i.e. your form) and the data (i.e. the list of items). In fact, this is considered bad practice in programming: when mixing business logic and display, there are several drawbacks. For example, you can not reuse the items you defined anywhere else, for example on another form. This approach is difficult to maintain when items change (even if it’s just the text), and so on. But anyway, you asked for it, here’s how it looks like:



On the data tab, there is another option: Lookups. While one may imply that lookups are not something static (the datatype can be “Static” or “Lookups”), strictly speaking they are. However, they are a big leap forward: there is a clear separation of the view and the model. Lookups foster reuse. Plus, they support multiple languages! Here’s how they look like. On the right hand side, a lookup containing capital cities is being defined in the Data module. On the left hand side, the lookup is consumed inĀ  data properties of a drop-down.


Dynamic Content

Here we are – content is generated dynamically, and probably does change over time. In addition, whenever any other system but TotalAgility decides which content to display, you may want to consider one of the following options. The following three methods seem to be the most likely ones you’ll apply when dealing with dynamic content, and they all are implemented as actions.

.NET Method

Working with your own .NET classes in TotalAgility is quite easy: here’s a very simple example. The following method returns a string array with three items:

public class KtaHelpers
        public string[] GetItems()
            List items = new List();
            return items.ToArray();

After the assembly is being added in the Integration module, we can call our GetItems method in an activity. We’ll just call the activity after the page loaded, and we’re set.

DB Query

The DB Query action is quite similar, however here we use the content from a database table. In my case, I have a table called Countries in my Demo database. The select statement returns multiple rows, and each row will become an entry in the drop-down.


Web Services

Well.. I think you get the point. Pretty much the same here, except that you’ll use a web service action here. I could not find any suitable web service, so sorry, no screenshots or code here.


This article should pretty much cover all the most likely options you will resort to when populating drop-downs. Different methods for dynamic and static content are covered in TotalAgility, and some methods seem more suitable than others, depending on your current use case. For example, when working with cascading drop-downs, I’d go for a .NET method that populates (and eventually clears) multiple drop-downs at once. When confronted with data from external systems, I’d stick with the DB query, and maybe I can even find a use case for web services, who knows. Also, static content is covered nicely – as long as you’ll stick with Lookups.

And by the way, kudos to Adam, Phong, and Shane who helped me come up with all the options in the first place.