4th Dimension Learning Basics

Before you can design a single table, build a form, or wire up a value list in 4D (4th Dimension), you have to be fluent in the vocabulary of the environment you’re working in. Much of that vocabulary lives in the menu system — the strip of commands running across the top of every window.

This article is the first in a series on menus, and it starts where any good technical discussion should: with precise definitions. Getting the terminology right now saves hours of confusion later, because 4D’s documentation, its Design environment, and the running application all reuse these same words in specific ways.

Key Takeaways

• The Menu Bar is the horizontal strip at the top of the screen; the names on it are Menus; the selectable entries beneath them are Menu Items.
• Symbols to the right of a Menu Item are keyboard shortcuts; an arrowhead indicates a Sub Menu; three trailing dots (an ellipsis) mean a menu window will open.
• These terms are not cosmetic — 4D’s own menu editor and command language depend on you distinguishing a menu from a menu item.
• Understanding the anatomy of a menu is the prerequisite for comparing 4D’s menus to FileMaker Pro’s and for building your own custom menus.
• A consistent menu vocabulary makes it far easier to read 4D documentation, follow tutorials, and communicate with other developers.

Why Definitions Come First

It is tempting to skip a section titled “Definitions.” Experienced developers assume they already know what a menu is. But 4D — like most mature development platforms — uses these words with more precision than everyday speech does, and the distinctions matter the moment you start customizing.

Consider a simple example. When someone says “add a command to the File menu,” they could mean two very different things:

• Add a new Menu Item to the existing File Menu (a single new command under an existing heading).
• Add an entirely new Menu to the Menu Bar (a new top-level heading alongside File, Edit, and the rest).

These are different operations with different consequences. If you and a colleague are using the same word for both, you will talk past each other. The same ambiguity shows up in written instructions, in bug reports, and in the 4D documentation itself. Nailing the terms down removes the ambiguity.

This is also why the series begins here rather than jumping straight into comparisons. The next articles contrast 4D’s menus with those of FileMaker Pro (FMP), propose a custom 4D menu, and walk through specific menu-by-menu suggestions. None of that lands cleanly unless the underlying vocabulary is shared.

The Anatomy of a Menu

Figure 1 in the original material shows a typical set of menus annotated with arrows and labels. Here is what each labeled part means, expanded with the practical detail you need to recognize them on screen.

Menu Bar

The Menu Bar is the bar at the top of the screen. It is the container for everything else — the horizontal strip that holds all the top-level menu names. In 4D, the Menu Bar is itself a manageable object: you can define which menus appear on it, and you can swap entire menu bars at runtime depending on context (for example, showing a different bar when a particular form is frontmost).

Think of the Menu Bar as the outermost layer of the hierarchy. Everything below it belongs to some menu on that bar.

Menus

The names listed in the Menu Bar are the Menus. “File,” “Edit,” “Records,” “Records,” and so on are menus. A menu is a named grouping of related commands. Its job is organizational: it collects Menu Items that belong together conceptually so users can find them.

A menu is not the same as its contents. You can have an empty menu (a heading with nothing under it), and you can add or remove items from a menu without changing the menu’s identity.

Menu Items

The entries that can be selected when a menu drops down are Menu Items. These are the actual commands — the things that do work when clicked. “New,” “Open,” “Save,” “Print” are all Menu Items.

Menu Items are where the action lives. When you build a custom menu in 4D, most of your effort goes into defining Menu Items and attaching methods (code) to them. A Menu Item can be:

• Enabled or disabled — greyed out when the command isn’t currently valid.
• Checked or unchecked — showing a checkmark to indicate a toggle state.
• Bound to a method — running your code when selected.

Keyboard Shortcuts

If there are symbols to the right of a Menu Item, they indicate the keyboard shortcut keys that will select the same Menu Item. A shortcut is an alternative way to trigger a command without opening the menu.

Shortcuts are a usability feature, not a separate command. The same Menu Item can be reached either by clicking it or by pressing its shortcut. When you define a custom Menu Item in 4D, you can assign a shortcut to it, and it’s good practice to follow platform conventions — for instance, using the standard modifier key (Command on macOS, Control on Windows) for common actions like Save or Print, so the shortcut feels native to users on each platform.

Sub Menus

If there is an arrowhead to the right of a Menu Item, clicking on that will display a Sub Menu. A Sub Menu is a nested menu — a menu inside a menu. It lets you group a large number of related commands under a single parent item without cluttering the top level.

Sub Menus are useful when a category has many members. Rather than listing twenty report commands directly in a menu, you might create a single “Reports” item that opens a Sub Menu containing all twenty. The trade-off is discoverability: commands buried one level deeper take an extra click and an extra moment of hunting, so reserve Sub Menus for genuinely large or secondary groups.

Menu Windows

Menu Items with three dots after them (for example, “Sharing …”) when clicked will show a menu window with choices. The trailing ellipsis is a widely followed interface convention, not unique to 4D: it signals that selecting the item will not act immediately but will instead open a dialog or window that asks for more information before anything happens.

This is a small but important distinction for users. A Menu Item with no ellipsis does its job the instant you click it. A Menu Item with an ellipsis is the beginning of a conversation — it opens a window where you make further choices, then confirm or cancel.

The Menu Hierarchy at a Glance

The parts described above form a strict hierarchy. Keeping the levels straight is the single most useful mental model you can carry into the rest of this series.

Level	Term	What it is	Example
1	Menu Bar	The horizontal strip at the top of the screen	The whole bar containing File, Edit, Records…
2	Menu	A named heading on the Menu Bar	”File”
3	Menu Item	A selectable command inside a menu	”Open”
4	Sub Menu	A nested menu opened from a Menu Item	”Reports ▸“
—	Keyboard Shortcut	Symbols to the right of an item	⌘S / Ctrl+S
—	Menu Window	A dialog opened by an item with ”…"	"Sharing…”

Read the table top to bottom and you have the containment relationship: the Menu Bar contains Menus, Menus contain Menu Items, and a Menu Item can open either a Sub Menu (another menu) or a Menu Window (a dialog). Shortcuts and ellipses are annotations on Menu Items rather than separate levels.

How to Decide: Practical Guidance for Menu Design

Definitions are only useful if they change what you do. Here is how the vocabulary above translates into concrete decisions when you build menus in 4D.

• Choosing between a Menu Item and a Sub Menu. If a category has only a handful of commands, list them directly as Menu Items. If it has many, or if the commands are secondary, group them under a Sub Menu. The cost of nesting is an extra click, so don’t nest for its own sake.
• Deciding whether to use an ellipsis. Add the trailing dots whenever selecting the item opens a window or dialog that requires further input before the action completes. Omit them when the command acts immediately. Consistency here trains users to predict behavior.
• Assigning keyboard shortcuts. Reserve shortcuts for the commands users reach for most often, and follow platform conventions so muscle memory carries over from other applications. Over-assigning shortcuts creates collisions and confusion.
• Enabling and disabling items. A Menu Item that isn’t currently valid should be disabled (greyed out) rather than left clickable and failing silently. This is a courtesy to users and a common source of bug reports when neglected.
• Planning the Menu Bar per context. Because 4D lets you swap menu bars, decide early whether different forms or modes need different top-level menus, or whether one bar can serve the whole application.

Where This Fits in the Series

This article is deliberately foundational. The definitions above are the shared vocabulary the rest of the series relies on. From here, the material moves into comparisons and concrete recommendations:

• FMP vs. 4D Menus — how FileMaker Pro’s menu conventions differ from 4D’s, and what that means if you’re migrating or working in both.
• 4D Custom Menu — building your own menu structure rather than relying on defaults.
• File Menu Comparisons and File Menu Suggestions — a command-by-command look at the File menu and what belongs there.
• Other Menu Comparisons and Records Menu Suggestions — the same treatment for the remaining menus, with the Records menu getting particular attention because of how central record navigation is to database work.
• Custom Splash Screen — the finishing touch on a polished application shell.

If you’re coming to 4D from another environment, the comparisons will be the most immediately useful. If you’re new to database development entirely, spend extra time on the Records menu material, since record navigation is the daily bread of any data-driven application.

For readers who want to ground these interface concepts in the broader discipline of human-computer interaction, the work of Jakob Nielsen on usability heuristics and Ben Shneiderman’s “eight golden rules of interface design” are widely cited references on menu and command design; both are described in detail on Wikipedia and in standard HCI textbooks. The conventions described here — ellipses for dialogs, disabled states for invalid commands, consistent shortcuts — are direct applications of those principles.

Frequently Asked Questions

What is the difference between a menu and a menu item in 4D?

A menu is a named heading on the Menu Bar, such as “File” or “Records.” A menu item is a single selectable command inside that menu, such as “Open” or “Print.” The menu organizes; the menu item performs the action. Keeping the two distinct matters because adding a command and adding a menu are different operations.

What do the three dots after a menu item mean?

Three trailing dots — an ellipsis, as in “Sharing …” — signal that selecting the item will open a menu window or dialog rather than acting immediately. The user is expected to make further choices before the command completes. This convention is common across many platforms, not just 4D, so users often recognize it instinctively.

What does an arrowhead next to a menu item indicate?

An arrowhead to the right of a menu item means that item opens a Sub Menu — a nested menu containing additional commands. Sub Menus let you group many related commands under one parent item to keep the top-level menu tidy. The trade-off is that nested commands take an extra click to reach.

Are keyboard shortcuts the same as menu items?

No. A keyboard shortcut is simply an alternative way to trigger an existing menu item. The symbols shown to the right of an item tell you which keys will select that same command without opening the menu. The item and its shortcut do the same thing; the shortcut is a convenience, not a separate command.

Why does 4D bother distinguishing all these terms?

Because 4D’s menu editor, its command language, and its documentation all rely on these distinctions. When you customize menus, you manipulate menus, menu items, and menu bars as separate objects. Using the terms loosely leads to miscommunication with other developers and to mistakes when following instructions or reading reference material.

Do I need to understand menus before building forms and tables?

You can design tables and forms without touching menus, but you cannot ship a polished application without them. Menus are how users reach the commands that drive your forms and manipulate your data. Understanding the menu vocabulary early makes the later work of wiring up custom menus, value lists, and navigation far smoother.