4th Dimension Learning Basics

One of the most distinctive features of the 4D platform is its support for Custom Menus. Not only can you build your own menu bars, you can configure 4D to launch directly in Custom Menus mode, giving you complete control over the user’s experience from the moment the application opens. This is a significant departure from many rapid-application-development tools, where the menu bar is largely fixed by the framework and you are limited to enabling or disabling built-in commands.

With 4D Custom Menus you are allowed to modify the File Menu and add your own Menus and Menu Items between the Edit and Help Menus. The Edit and Help Menus are fixed — you cannot modify them. Everything else is yours to design.

Key Takeaways

• 4D Custom Menus let you replace the default menu bar with one you design, and you can set the application to open in Custom Menus mode for total control.
• You can modify the File Menu and insert your own menus and items between the Edit and Help menus, but the Edit and Help menus themselves are fixed.
• You can create multiple, different Menu Bars and assign each to a different situation — but overusing this is a fast route to confusing your users.
• Comparing your planned menu bar against what established programs use is a practical way to sanity-check your design before you commit to it.
• Menu design is a user-experience decision as much as a technical one; consistency and predictability matter more than cleverness.

Why Custom Menus Matter in 4D

In a traditional desktop application, the menu bar is the primary map of what the program can do. Users scan it to discover features, and they rely on it to be stable. When you ship a 4D application to a business team, the menu bar is often the first thing they interact with — before any form, list, or record is touched.

That makes the menu bar a design surface, not an afterthought. 4D recognizes this by letting developers take full ownership of it. The practical consequences are worth spelling out:

• You control discoverability. If a feature is important, you can put it in the menu where users will find it, rather than hoping they stumble onto a button.
• You control vocabulary. Built-in menu labels use generic terms. Your custom labels can use the language your users actually speak — “Post Invoice” instead of “Execute.”
• You control the launch experience. By opening in Custom Menus mode, you prevent users from wandering into default 4D menus that expose internals they should never touch.
• You control scope. You can hide entire categories of functionality from a given user group simply by not putting them in that group’s menu bar.

The trade-off is responsibility. Once you take over the menu bar, you own its consistency, its completeness, and its maintenance as the application grows.

What You Can and Cannot Change

Understanding the boundaries early saves a lot of frustration. The rules are straightforward:

• File Menu — modifiable. You can reshape it to match your application’s file-related operations.
• Edit Menu — fixed. You cannot modify it. This is deliberate: the Edit menu carries standard clipboard and editing behavior that users expect to behave identically across applications.
• Help Menu — fixed. Also unmodifiable, for the same reason — help access should be predictable.
• Between Edit and Help — your territory. This is where your own menus and menu items live.

The design logic behind fixing Edit and Help is sound and worth internalizing as a principle: standard behaviors should stay standard. Users build muscle memory around cut, copy, paste, undo, and help access. If every application redefined those, the platform would feel chaotic. 4D protects that baseline and gives you freedom everywhere else.

A useful mental model: think of the menu bar as having a reserved zone (Edit and Help) and an authoring zone (everything else). Your job is to make the authoring zone feel as inevitable and well-organized as the reserved zone.

Designing Your Menu Bar: Practical Guidance

Before you start clicking through the menu editor, decide what your application actually needs to expose. A menu bar is a hierarchy, and hierarchies are easy to get wrong.

Start from user tasks, not from your code structure

A common mistake is to mirror the internal structure of the database — one menu per table, one item per method. Users do not think in tables and methods. They think in tasks: “enter a new order,” “find a customer,” “run the monthly report.” Build the menu around those tasks.

Group by frequency and by risk

Place the most frequently used commands where they are easiest to reach. Place destructive or irreversible commands (delete, purge, archive) away from routine ones, and consider requiring confirmation. Menu placement is a form of error prevention.

Keep depth shallow

Two levels of nesting (menu → item) is comfortable for most users. Three levels (menu → submenu → item) is tolerable when the submenu is genuinely a category. Beyond that, users lose track of where they are. If you find yourself needing four levels, the feature probably belongs in a form or a dialog instead.

Use separators and consistent ordering

Separators group related items visually. Within a group, order items by expected frequency or by a logical sequence (for example, the order in which a workflow is performed). Keep that ordering stable across releases — reordering menus between versions is a subtle but real source of user frustration.

Write labels as verbs or clear nouns

“Print Invoice” is clearer than “Invoice Print.” “Reports” as a menu title is fine; “Report” as an item is ambiguous. Match the conventions your users already see in the other software they use daily.

Multiple Menu Bars: Power and Peril

4D lets you create multiple, different Menu Bars and assign each one to a different situation. This is genuinely powerful. Typical legitimate uses include:

• Role-based menus. A data-entry clerk sees a lean menu; a supervisor sees approval and reporting commands.
• Context-based menus. A menu shown while a record is open may differ from one shown on a search screen.
• Mode-based menus. A “setup” or “administration” mode can expose configuration commands that ordinary operation hides.

The original guidance here is worth repeating and emphasizing: I recommend caution here, as it can be very easy to confuse the user. Multiple menu bars multiply the number of states a user must track. If a command moves or disappears depending on context, users may conclude the feature is gone rather than relocated.

A practical rule of thumb:

Situation	Recommended approach
Different user roles need different capabilities	Separate menu bars — clear and justified
Same user, different screens	Prefer one stable menu bar; disable rather than remove items
Rarely used administrative tasks	A dedicated admin menu bar, gated by login
Minor contextual differences	Keep one menu bar; change item state, not layout

The principle: change availability, not location, whenever you can. A greyed-out item still tells the user the feature exists. A vanished item tells them nothing.

Comparing Against Established Programs

To help see what other programs are using for menu bars, it may be helpful to make a direct comparison. This is one of the most practical habits a 4D developer can adopt. Figure 5 in the original material shows a comparison of just the Menu Bars — a side-by-side of how different applications arrange their top-level menus.

The value of this exercise is that menu conventions are largely inherited, not invented. Decades of desktop software have converged on a rough consensus about what belongs where. Studying that consensus — in word processors, spreadsheets, database clients, and accounting packages — gives you a baseline you can either follow or deliberately depart from.

When you compare menu bars, look for:

• Top-level count. Most mature applications settle on a small number of top-level menus. A bar with a dozen entries feels cluttered.
• Naming conventions. Notice how consistently “File,” “Edit,” “View,” “Tools,” and “Help” are used, and where applications insert their own domain menus.
• Placement of domain-specific menus. Where does a vertical application put its industry-specific commands? Usually after the standard menus and before Help — exactly the zone 4D leaves open to you.
• Item density. How many items sit under each menu, and how are they separated?

For background on the conventions themselves, the Wikipedia article on the menu bar and the File menu are useful references for understanding where these patterns came from and why they persist.

A Worked Example: Menu Bar for a Small Order-Tracking App

Suppose you are building a modest order-tracking application for a small business. A sensible custom menu bar might look like this:

• File — New Order, Open Order, Print, Print Preview, Exit
• Edit — (fixed; left as-is)
• Orders — Enter Order, Find Order, Post Order, Void Order
• Customers — New Customer, Find Customer, Customer History
• Reports — Daily Summary, Monthly Summary, Backorder Report
• Help — (fixed; left as-is)

Notice several deliberate choices. The domain menus (Orders, Customers, Reports) sit between Edit and Help, exactly where 4D permits them. Destructive commands (Void Order) are grouped at the end of their menu, separated from routine entry. The Reports menu is a flat list rather than a nested hierarchy, because there are only three reports. If the report list grew to fifteen, a submenu by category would become justified.

Now consider the role variation. A warehouse clerk might get the same bar minus the Reports menu. A manager gets the full bar. That is a legitimate use of multiple menu bars. But if the clerk’s bar also reordered Orders items differently from the manager’s, you would be creating confusion for no benefit.

Common Pitfalls to Avoid

• Exposing default 4D menus by accident. If you do not set the application to open in Custom Menus mode, users may reach built-in menus that expose design-mode functionality. Lock this down early.
• Duplicating commands in multiple menus. If “Print” appears under both File and Reports, users wonder whether they differ. Pick one home per command.
• Using menu items as the only path to a feature. Menus are for discoverability; frequently used actions should also be reachable from forms and toolbars.
• Forgetting keyboard shortcuts. Menu items without shortcuts force mouse use. Assign conventional shortcuts where they exist.
• Never revisiting the design. Menu bars accumulate cruft. Review yours each release and remove what is no longer used.

How This Fits the Broader 4D Learning Path

Custom menus sit alongside several other foundational 4D skills covered in this series: understanding definitions and terminology, comparing 4D’s menus to those of FileMaker Pro, shaping the File menu specifically, and building a custom splash screen. Together these form the presentation layer of a 4D application — the parts a user sees before they ever touch your data model.

The through-line is control. 4D gives you an unusual degree of control over the user-facing shell of your application. Custom menus are one of the clearest expressions of that philosophy, and mastering them early pays dividends as your application grows in scope and audience.

Frequently Asked Questions

Can I modify the Edit and Help menus in 4D?

No. The Edit and Help menus are fixed and cannot be modified. This is intentional, because these menus carry standard behaviors — clipboard operations, undo, and help access — that users expect to remain consistent across applications. Your customization happens in the File menu and in the space between Edit and Help.

Where do my custom menus and menu items appear?

Your own menus and menu items are inserted between the Edit and Help menus. This is the authoring zone 4D reserves for developers. The File menu is also modifiable, while Edit and Help are not.

Should I create multiple menu bars for my application?

Only when the difference is genuinely justified — most commonly for distinct user roles or an administrative mode. Multiple menu bars multiply the states a user must track, and it is very easy to confuse people. When in doubt, keep one menu bar and change item availability rather than layout.

What does “opening in Custom Menus mode” actually do?

It tells 4D to launch your application using your custom menu bar rather than the default 4D menus. This gives you complete control over the program’s user-facing shell and prevents users from reaching built-in menus that expose internals they should not see.

How do I know if my menu bar design is any good?

Compare it directly against established programs. Menu conventions are largely inherited rather than invented, so studying how word processors, spreadsheets, and database clients arrange their top-level menus gives you a reliable baseline. Look at top-level count, naming, placement of domain-specific menus, and item density.

Is it a problem if a menu item disappears in some contexts?

It can be. A greyed-out item still tells the user the feature exists; a vanished item tells them nothing and may lead them to think the feature was removed. Prefer changing availability over changing location whenever you can.