4th Dimension Learning Basics

Understanding the Fixed Menus in 4D

When you build a custom application in 4D (4th Dimension), one of the first things you discover is that not every part of the menu bar is yours to control. The Edit and Help menus are fixed: they are supplied by the 4D environment itself, they appear in every compiled and interpreted application, and their menu items cannot be renamed, reordered, or removed through the standard menu editor.

This surprises developers coming from FileMaker Pro, where the menu system is comparatively open and where you can often suppress or replace large portions of the default menu bar. In 4D, the platform reserves a small but important slice of the interface for itself. Understanding why those menus are fixed — and what you can still do around them — is a core piece of 4D literacy.

Figure 10 in the original lesson shows the 4D “Edit” and “Help” menus side by side. The lesson’s point is simple and worth restating: all programs will have these menus and menu items. You do not get to opt out. What you can do is design the rest of your menu bar so that the fixed menus feel like a natural part of your application rather than an intrusion.

Why 4D Reserves the Edit and Help Menus

The fixed menus exist because 4D is both a development environment and a runtime. The same menu machinery that lets you edit a method in the Design environment also has to serve text entry in a form field at runtime. The Edit menu carries the standard clipboard and text-editing commands — Undo, Cut, Copy, Paste, Clear, Select All — that users expect in any text field, whether that field is a 4D data entry area, a comment box, or a search bar.

The Help menu, meanwhile, is the platform’s hook for its own documentation, “About” information, and version reporting. Because 4D ships as a single engine across interpreted and compiled modes, and across Windows and macOS, the vendor keeps these two menus under its own control to guarantee consistent behavior regardless of what the developer does.

A few practical consequences follow from this:

• You cannot delete them. Attempting to remove Edit or Help from the menu bar is not supported. The menu bar command set in 4D works with the menus you define; the fixed menus sit outside that scope.
• You cannot rename their items. “Undo,” “Paste,” and “Select All” will always read that way (subject to the OS language).
• Their behavior is tied to the focused object. The Edit menu’s items enable and disable automatically depending on whether a text-input object has focus. This is a feature, not a limitation — it means you get correct clipboard behavior in every entry field for free.
• They appear in both modes. Interpreted (Design/User) and compiled (merged) applications both show them.

The takeaway for a citizen developer or small-team builder is that you should treat Edit and Help as platform furniture. Design around them rather than fighting them.

How the Fixed Menus Interact With Your Custom Menus

The original lesson sits inside a larger sequence about menus: comparing FileMaker Pro and 4D menus, building a custom 4D menu, and then working through File, Records, and “other” menu comparisons. The Edit/Help discussion is the “other” category — the menus you don’t get to author.

The important design question is ordering and grouping. In 4D you build your custom menu bar with commands such as INSERT MENU, APPEND MENU ITEM, and their relatives, and you attach the bar to a form or to the application. The fixed menus occupy conventional positions:

• Edit typically sits after File and any custom menus you insert near the front.
• Help conventionally sits at the far right of the menu bar on both Windows and macOS.

Because you cannot move them, the practical guidance is to place your own menus so the fixed ones land where users expect them. If you insert a “Records” menu and a “Reports” menu, think about whether Edit should fall between them or after them. Most users have a strong muscle-memory expectation that Help is last and Edit is somewhere in the left-to-middle region. Honor that.

A useful mental model is the menu bar as a contract:

Region	Who controls it	What belongs there
File	You (customizable)	New, Open, Save, Print, Quit-style actions
Edit	4D (fixed)	Undo, Cut, Copy, Paste, Clear, Select All
Records	You (customizable)	Navigation, create/delete record, search
Custom menus	You	Your app’s domain actions
Help	4D (fixed)	Platform help, About, version info

If you keep your custom menus in the “you” rows and leave the fixed rows alone, your menu bar will read naturally to anyone who has used a desktop application before.

What You Can Still Customize Around Them

The fixed menus do not mean the menu bar is frozen. There is a great deal you control, and knowing the boundary lets you spend your effort where it counts.

• Your own top-level menus. File, Records, and any domain-specific menus (Reports, Utilities, Admin) are yours to define, name, and populate.
• Menu items and submenus. You can add items, separators, checkmarks, keyboard shortcuts, and nested submenus within your menus.
• Enable/disable logic. You can gray out your own items contextually — for example, disabling “Delete Record” when no record is selected — using 4D’s menu item state commands.
• Contextual menus. Right-click (contextual) menus are a separate mechanism from the menu bar and are fully under your control, so they are a good place to surface actions that would otherwise clutter the fixed-adjacent bar.
• The About/Help experience. While you cannot rewrite the Help menu’s built-in items, you can add your own “About MyApp” or “Documentation” command inside one of your custom menus, giving users a branded path to your help content.

The pattern that works well: keep the fixed menus lean and untouched, and route all application-specific help and “about” information through your own menu items. That way the platform’s Help menu stays as the escape hatch to 4D’s own documentation, and your users still find your material.

Practical Guidance: Designing a Menu Bar That Coexists With Fixed Menus

When you sit down to lay out the menu bar for a new 4D application, work through these decisions in order:

1. List the verbs your users need. Create, find, edit, delete, print, export, navigate, administer. Group them by noun.
2. Map each group to a top-level menu. Records, Reports, Utilities, and so on.
3. Reserve the conventional slots. Let File lead, let Edit sit in its natural place, and let Help close the bar.
4. Decide what goes in contextual menus. Anything that is only relevant to a selected object (a row, a field, a record) is often better as a right-click action than a menu-bar item.
5. Plan enable/disable rules. For each custom item, ask “when should this be grayed out?” and wire that logic early rather than retrofitting it.
6. Test in both modes. Verify the menu bar behaves correctly in interpreted and compiled builds, and on both Windows and macOS if you ship cross-platform.

A common mistake among developers new to 4D is to try to replicate the Edit menu’s functions inside a custom menu — adding their own “Copy” and “Paste” items. This creates duplicate commands, confuses users, and usually behaves worse than the built-in items because the platform’s versions are already wired to the focused text object. Don’t reinvent the fixed menus; complement them.

Another mistake is to bury critical actions so deep in custom submenus that users never find them, while the fixed Edit and Help menus sit prominently at the edges. Use the visual weight of the fixed menus as an anchor: put your most-used commands in top-level menus near them, not three levels down.

How This Differs From FileMaker Pro

The original lesson explicitly frames this section as part of a FileMaker Pro vs. 4D comparison, and the Edit/Help point is one of the clearest divergences. FileMaker Pro gives developers a comparatively open menu system — you can build custom menus, and with the relevant configuration you can hide or replace large parts of the default menu bar. 4D takes a more conservative stance: a defined set of platform menus is always present.

Neither approach is objectively better; they reflect different philosophies.

• FileMaker’s flexibility suits developers who want total control of the user’s visual environment and are willing to take responsibility for providing every command the user needs.
• 4D’s fixed menus guarantee that standard text editing and platform help are always available, which reduces the chance that a user gets stuck in a field with no way to paste, or in an app with no route to documentation.

For a small-team builder, 4D’s stance is often the easier one to live with, because it removes a whole category of decisions. You never have to ask “should I provide my own Copy command?” — the answer is already no.

Key Takeaways

• The Edit and Help menus in 4D are fixed: they appear in every application and their items cannot be renamed, reordered, or removed.
• They exist because 4D is both a development environment and a runtime, and the platform needs guaranteed clipboard and help behavior in every text field.
• You still control File, Records, and all your own custom menus, plus contextual menus and enable/disable logic.
• Design around the fixed menus: place your custom menus so Edit and Help land where users expect them, and never duplicate the built-in clipboard commands.
• Route your own “About” and documentation through custom menu items rather than trying to alter the Help menu.
• This is a key contrast with FileMaker Pro, which offers developers far more menu-bar control.

Frequently Asked Questions

Can I remove the Edit or Help menu from a 4D application?

No. These menus are supplied by the 4D environment and are present in every application, interpreted or compiled. The menu commands you use to build a custom menu bar operate on the menus you define, not on the platform’s fixed menus. The practical approach is to design your own menus so the fixed ones sit in their conventional positions.

Why does 4D keep the Edit menu fixed instead of letting developers customize it?

Because 4D serves both as a development environment and a runtime, the platform needs reliable clipboard and text-editing behavior in every text-input object. By keeping Undo, Cut, Copy, Paste, Clear, and Select All under its own control, 4D guarantees those commands work correctly and consistently regardless of what the developer builds, and across Windows and macOS.

Should I create my own Copy and Paste menu items?

Generally no. The built-in Edit menu items are already wired to the focused text object and enable or disable automatically. Adding your own duplicates creates confusion and usually behaves worse. Instead, spend your menu-design effort on domain-specific commands that the platform does not provide.

Where should my custom menus go relative to the fixed ones?

Follow desktop conventions: let File lead the bar, allow Edit to sit in its natural left-to-middle position, and let Help close the bar on the right. Insert your own menus — Records, Reports, Utilities — so they group logically without pushing the fixed menus into unexpected places. Users rely on muscle memory for where Edit and Help live.

Can I add my own “About” or help command if the Help menu is fixed?

Yes — just not inside the Help menu itself. Add an “About MyApp” or “Documentation” item to one of your own custom menus. This gives users a branded path to your help content while leaving the platform’s Help menu intact as the route to 4D’s own documentation.

Does the fixed-menu behavior differ between interpreted and compiled 4D applications?

The Edit and Help menus appear in both modes, so the constraint is the same whether you are running in the Design/User environment or shipping a merged, compiled application. What changes between modes is other behavior — debugging, method access, and so on — but the fixed menus remain fixed throughout.