4th Dimension Learning Basics

If you are coming to 4D (4th Dimension) from FileMaker Pro, one of the first mental adjustments you have to make is around value lists. FileMaker gives you a friendly, self-contained dialog for building them.

4D gives you something more powerful but less hand-holding: the List Editor, a design-mode tool that produces reusable list resources you then attach to form objects. This article walks through how value lists work in 4D, how they differ from FileMaker’s approach, and the practical decisions you’ll make along the way.

Key Takeaways

• In 4D, value lists are created and stored centrally in the List Editor, not inside individual field definitions as in FileMaker.
• A 4D list is a named resource; the same list can be attached to many form objects across many forms, which keeps maintenance in one place.
• List items support per-item formatting (plain, bold, italic) and an editable flag, and each item can carry child items to arbitrary depth — a hierarchical structure FileMaker’s flat value lists don’t offer natively.
• FileMaker’s four display styles (Popup List, Popup Menu, Check Boxes, Radio Buttons) map onto 4D concepts, but only the Popup List is straightforward; checkboxes and radio buttons require considerably more work.
• The right time to build a list is before you wire up the form object that uses it, so you can reference it by name immediately.

Why 4D Calls Them “Lists” and FileMaker Calls Them “Value Lists”

Terminology is the first hurdle. FileMaker’s documentation and UI use Value List consistently. 4D documentation and the classic HPO Soft training material use List, and you’ll also see Choice List in older references and community posts. They all describe the same idea: a named collection of items that a user picks from when entering data into a field.

The naming difference reflects a real architectural difference. In FileMaker, a value list is essentially a property of the field or the layout object — you define it in the context of where it’s used, and FileMaker offers three sources:

• A custom list of items you type in yourself.
• A list derived from field values — unique values pulled from records in the current file, or values reached through a relationship.
• A list based on a list in another file (a related file’s value list).

4D supports the same three sources conceptually, but it separates the list definition from the list usage. You define the list once in the List Editor, give it a name, and then any form object — a popup, a dropdown, a combo box, a tab control, whatever — can point at that name. That separation is the single most important thing to internalize, because it changes how you plan your schema and your forms.

Creating a List in the 4D List Editor

The workflow is short but worth doing in the right order.

1. Switch to Design mode. Lists are design-time resources, not runtime data.
2. Open the Tools menu and choose List Editor. (In modern 4D this lives under the Design menu / Explorer depending on version, but the classic path is Tools → List Editor.)
3. The List Editor window opens with two sub-windows: List of Lists on the left and Current List on the right.
4. In the left pane, click Add and type a name for your new list. Choose the name carefully — it becomes the identifier you’ll reference from form objects, and renaming later means updating every reference.
5. Click the name to select it, then move to the right pane and enter the items for that list, one per line.

That’s the whole creation loop. The interesting part is what you can do to each item once it exists.

Per-item formatting and editability

Each list item carries its own display attributes:

• Plain text (the default)
• Bold
• Italic
• Bold and italic

Because these apply per item, a single list can mix styles — useful for visually flagging a default choice, a deprecated option, or a category header inside the list.

There is also an editable flag per item. When an item is marked editable, the user can modify that entry rather than being locked to the predefined text. This is a subtle but powerful distinction: it lets you ship a list that is mostly controlled vocabulary but allows controlled free-text escape hatches where the business genuinely needs them. Use it sparingly — once users can edit list items, your data consistency guarantees weaken, and reporting on that field becomes harder.

Child items: hierarchical lists

The feature that most surprises FileMaker veterans is Add a Child. Any list item can have a sub-item, and that sub-item can have its own sub-item, and so on. You are effectively building a tree.

This matters because many real business vocabularies are hierarchical:

• Product categories → subcategories → SKUs
• Regions → countries → cities
• Departments → teams → roles
• Chart of accounts → account groups → individual accounts

In FileMaker you’d typically model this with a self-relationship and a portal, or flatten it into a single list with naming conventions. In 4D you can express the hierarchy directly in the list resource and let the form object present it as an indented menu. That’s a genuine advantage for anyone building pickers over structured reference data.

How Lists Attach to Form Objects

Once a list exists, you attach it to a form object — most commonly a popup list (also called a dropdown or popup menu depending on the object type and version). The mechanics:

• Select the field or variable object on the form in Design mode.
• Open the object’s Properties list.
• Find the Choice List / List property and select your named list from the picker.

Because the list is referenced by name, the same list can drive a popup on an entry form, a search form, and a report filter — all pointing at one definition. Change the list once, and every consumer updates. That’s the payoff for the extra design-time ceremony.

A practical caveat: if you delete or rename a list that form objects reference, those objects lose their list silently in some versions. Before renaming, search your forms for the old name. Treat list names as part of your application’s public interface.

Display Styles: What Maps Cleanly and What Doesn’t

FileMaker offers four display styles for value lists. Here’s how they translate to 4D in practice.

FileMaker display style	4D equivalent	Difficulty in 4D
Popup List	Popup / dropdown list object	Straightforward — the recommended starting point
Popup Menu	Popup menu object	Straightforward
Check Boxes	Checkbox object bound to a list	Significantly more complex; typically needs multiple objects or a list-of-values field
Radio Buttons	Radio button group	Significantly more complex; usually built from individual radio objects

The honest summary, and the one the original HPO Soft material makes: only the Popup List is described here, because it’s the path of least resistance. Checkbox and radio-button value lists are possible in 4D, but they are much more involved than their FileMaker counterparts. If you’re migrating a FileMaker solution and it leans heavily on checkbox value lists, budget real time for that conversion — it is not a one-to-one port.

Choosing the Right List Source

Before you open the List Editor, decide where the items come from. This decision drives everything downstream.

• Static custom list — you type the items. Best for small, stable vocabularies: status codes, salutations, priority levels, yes/no/unknown. Fast to build, no runtime cost, but every change requires a design-mode edit and a redeploy.
• List derived from field values — items come from the unique values already present in a field. Best when the vocabulary is data-driven and grows organically, e.g. a “customer type” field populated by other parts of the system. The trade-off: the list is only as clean as your data, and it can’t offer values that don’t yet exist in any record.
• List based on another file / related list — items come from a related table or another file’s list. Best for shared reference data (a central lookup table of departments, currencies, or product lines) that multiple parts of the application must agree on. This is the most maintainable option for anything that changes over time, because you update the source table, not the list.

A useful rule of thumb: if more than one form needs the list, or if the list will change without a code release, drive it from data rather than typing it in. Static lists are for things that are genuinely fixed — and genuinely fixed things are rarer than people assume.

Practical Guidance and Common Pitfalls

A few hard-won habits make list work in 4D much less painful:

• Name lists with a prefix and a purpose. Something like lst_Status_Order or lst_Region_Sales tells a future maintainer what the list is for and where it’s used. Avoid generic names like List1.
• Build the list before the form object. If you create the popup first, you’ll be editing the object’s properties twice.
• Keep static lists short. A static list with fifty entries is a maintenance liability; that’s a data-driven list wearing a costume.
• Be deliberate about editable items. Every editable item is a hole in your data validation. Document why each one exists.
• Use child items for genuine hierarchies, not for decoration. Indentation that doesn’t reflect a real parent-child relationship confuses users more than it helps.
• Watch for orphaned references. When you retire a list, grep your forms for its name before deleting it.

For broader context on how 4D fits into the low-code and rapid application development landscape, the platform’s own documentation and community forums are the authoritative sources; the 4D developer documentation covers the current List Editor UI, which has evolved since the classic HPO Soft material was written. For background on the relational model that underpins tables, fields, and lookups, see the Wikipedia article on the relational model, and for the general category of tools this work belongs to, the Wikipedia overview of low-code development platforms is a useful orientation.

Where Lists Fit in the Bigger Build

Value lists are step six in a sequence that runs: create a database → set database properties → define tables → define data fields → build forms → create value lists → enter sample data. Notice that lists come after forms and before sample data. That ordering is deliberate and worth respecting: you want your form objects in place so you can attach lists to them, but you want lists finished before you start entering sample records, because sample data is where you’ll discover whether your lists actually cover the real-world cases.

If you skip ahead and enter sample data first, you’ll find yourself re-entering records every time you refine a list. Do the lists first, then populate.

Frequently Asked Questions

What is the difference between a value list in FileMaker and a list in 4D?

FileMaker defines value lists in the context of the field or layout object that uses them, and offers three sources: custom items, values from records or a relationship, and a list from another file. 4D separates the definition from the usage: you create a named list once in the List Editor, then attach that name to any number of form objects. The 4D approach is more work up front but far more maintainable when many forms share the same vocabulary.

Can 4D create checkbox and radio button value lists like FileMaker?

Yes, but it is considerably more complex than in FileMaker. FileMaker lets you pick “Check Boxes” or “Radio Buttons” as a display style directly on a value list. In 4D, achieving the same behavior typically requires multiple form objects or a list-of-values field, and the original HPO Soft training material deliberately covers only the Popup List for this reason. Plan extra time if you’re migrating a FileMaker solution that relies on checkbox lists.

What are child items in a 4D list, and when should I use them?

A child item is a sub-item nested under a parent list item, and nesting can continue to any depth. Use them when your vocabulary is genuinely hierarchical — product categories and subcategories, regions and cities, departments and teams. Don’t use them for visual grouping alone, because indentation implies a parent-child relationship that users will expect to mean something.

Should I use a static list or a data-driven list?

Use a static custom list for small, stable vocabularies that rarely change, such as status codes or priority levels. Use a list derived from field values or from a related file when the vocabulary grows over time or is shared across multiple forms. A good rule: if the list will change without a code release, or if more than one form needs it, drive it from data rather than typing items in by hand.

What does the “editable” option on a list item do?

Marking a list item editable lets the user modify that entry instead of being restricted to the predefined text. It’s useful when you want a mostly controlled vocabulary with a few controlled free-text escape hatches. Use it sparingly, because editable items weaken your data consistency guarantees and make reporting on that field less predictable.

When in the build process should I create my value lists?

Create lists after your forms exist but before you enter sample data. You need the form objects in place so you can attach lists to them by name, and you want the lists finished before sample entry so you don’t have to re-enter records every time you refine a list. Following the sequence — tables, fields, forms, lists, then sample data — saves real rework.