4th Dimension Learning Basics

The File menu is the first thing a user touches in any custom 4D application, and it is also the menu most likely to be left in its default state by developers who are eager to move on to forms and methods. That is a mistake.

The File menu is where your application declares what it is for — whether it is a data-entry tool, a reporting tool, or a general-purpose business application. Getting it right early saves rework later, because menu items are wired to methods, and methods are wired to your table structure.

This section walks through the recommended File menu for a custom 4D menu bar, how to build it in the Menu Bar Editor, and the practical constraints you will hit along the way.

Key Takeaways

• A well-designed custom File menu typically contains four logical groups: data movement (Import/Export), printing (Page Setup, Print Record, Print Found Set), application identity (About), and exit (Quit).
• Menu bars in 4D are permanently named Menu Bar #1, Menu Bar #2, and so on — you cannot rename them, so document which bar serves which purpose.
• Divider lines are created as menu items themselves using the Line option; they are not a separate property.
• Menu item names are fixed once created. You can delete and recreate an item, but you cannot edit its label in place.
• Reordering is asymmetric: you can drag items up freely, but to move an item down you must drag other items above it.
• Keyboard shortcuts and attached methods are configured per menu item, and methods are the bridge between the menu and your application logic.

Why the File Menu Deserves Deliberate Design

In FileMaker Pro, the File menu is largely fixed — you get what the platform gives you, and customization happens at the level of scripts and buttons rather than the menu bar itself. 4D inverts that relationship. The menu bar is a first-class design object, edited in Design Mode through the Menu Bar Editor, and every item in it can carry its own keyboard shortcut and its own method.

That power comes with responsibility. A custom File menu that mirrors the FileMaker layout out of habit will feel wrong to 4D users, while a File menu that omits printing entirely will frustrate anyone who expects standard desktop behavior. The goal is a menu that is recognizable — it does what a File menu is expected to do — while being specific to your application’s workflow.

The recommended structure for this series is deliberately small:

File
  Import Data
  Export Data

Page Setup
  Print Record
  Print Found Set

About A

Quit        Q

Each group answers a different user question. The first group answers “how do I get data in and out?” The second answers “how do I get this onto paper?” The third answers “what am I running?” The fourth answers “how do I leave?” That is a coherent mental model, and users navigate it without instruction.

Building the File Menu in the Menu Bar Editor

The mechanics are straightforward but full of small traps. From Design Mode, open the Tools menu and choose Menu Bar Editor. You will see a “List of Menu Bars” window on the left and a “Current Menu Bar” window on the right.

1. In the “List of Menu Bars” window, click Menu Bar #1. Note that menu bar names are not editable — they are always Menu Bar #1, Menu Bar #2, and so on. If you maintain several bars (for example, one for data entry and one for reporting), keep a separate note mapping each numbered bar to its purpose. This is one of the few places in 4D where you must maintain external documentation to stay sane.
2. In the “Current Menu Bar” window, click the File menu to select it as the target.
3. Click Add Item to append a new entry, then type its name.
4. To insert a divider, add another item and choose the Line option instead of typing a name.
5. Repeat until the menu matches your intended structure.

The constraints you will actually hit

• Names are immutable. Once a menu item is created, you cannot rename it. If you typo “Export Data” as “Exprot Data,” your only fix is to delete the item and create a new one — which also means reattaching any method and shortcut you had already configured. Type carefully the first time.
• Dragging is one-directional in practice. You can drag items upward freely. To move an item down, you must drag the items above it upward past it. Plan your order before you start adding, or accept some shuffling.
• Dividers count as items. A divider occupies a slot in the ordering, so it participates in the same drag rules as a named item. Insert dividers after you have the named items in roughly the right order.

Figure 8 in the original walkthrough shows the “Add Item” workflow against the File menu, and Figure 9 shows the resulting custom File menu as the user will see it at runtime. It is worth previewing the menu after each group of additions rather than building the whole thing blind.

Choosing What Belongs — and What Does Not

The temptation with a customizable menu bar is to expose everything. Resist it. Every item you add is a promise that the feature works, is discoverable, and has a sensible keyboard shortcut. A short File menu that is fully wired beats a long one with dead entries.

A useful decision framework:

Candidate item	Include when…	Consider omitting when…
Import Data	Users regularly bring in external files (CSV, tab-delimited, spreadsheet exports)	Data arrives only through your own forms or an automated sync
Export Data	Users need to hand data to Excel, another system, or a colleague	Reporting is fully handled by printed output or on-screen lists
Page Setup	Any printing happens at all	The application is screen-only
Print Record	Users print the record currently on screen	Printing is always a found set or a report
Print Found Set	Users work with query results and need them on paper	Printing is always single-record
About	You want version and support information reachable in one click	The application is internal and versioning is handled elsewhere
Quit	Always — users need a clean exit that can run cleanup code	Never omit this; a missing Quit forces OS-level window closing

The Quit item deserves special mention. In 4D, Quit can be attached to a method that performs orderly shutdown — closing windows, committing or cancelling transactions, releasing locks, writing a session log. If you omit Quit from the menu, users will close the application window instead, and your cleanup method never runs. That is a data-integrity risk, not a cosmetic one.

Similarly, About is more than vanity. A well-built About item can display the application version, the 4D engine version, the current data file path, and a support contact. When a user calls for help, “click About and read me the first three lines” resolves a surprising number of support tickets before they escalate.

Keyboard Shortcuts and the Method Connection

Two properties attach to each menu item beyond its name: a keyboard shortcut and a method.

Keyboard shortcuts follow desktop conventions closely enough that users will guess them. The conventional pairings are Command-Q (macOS) or the equivalent platform accelerator for Quit, and Command-P for printing. When you assign shortcuts, check for collisions — two menu items sharing an accelerator means one of them silently never fires, and the user will report it as “the menu item does nothing.”

Methods are the 4D equivalent of FileMaker scripts, and they are what make a menu item do something. A menu item with no method is inert: it appears, it highlights, and clicking it accomplishes nothing. This is the single most common defect in a first custom menu bar. Before you consider the File menu finished, walk every item and confirm it has either a method attached or a deliberate reason for being decorative.

The division of labor is worth stating plainly:

• Menu items handle discovery and invocation.
• Methods handle logic, validation, error handling, and user feedback.
• Forms and list boxes handle the actual data presentation.

Keeping those layers separate is what makes a 4D application maintainable. A menu item whose method is a single line calling a well-named project method is far easier to debug than one whose method contains fifty lines of inline logic.

Methods are covered in a later part of this series; for now, the important thing is to leave the hook in place. Adding the menu item and attaching a stub method early means you can wire the real logic later without revisiting the Menu Bar Editor.

Common Mistakes and How to Avoid Them

• Building the menu before the data model. Menu items imply capabilities. If you add “Export Data” before you have decided which tables and fields are exportable, you will either ship a half-working export or rewrite the menu later.
• Forgetting the divider items. Without dividers, a File menu with eight entries reads as an undifferentiated list. The visual grouping is what makes the structure legible.
• Assuming you can rename later. You cannot. Decide on labels — including capitalization and pluralization — before you click Add Item.
• Leaving Quit unwired. As noted, this pushes users toward window-closing and skips your cleanup logic.
• Duplicating FileMaker conventions wholesale. 4D’s menu bar is more flexible than FileMaker’s, so copying the FileMaker File menu exactly wastes the platform’s advantage. Design for your users, not for a different product.

Where This Fits in the Series

This section covers the File menu specifically. The surrounding parts of the series address how 4D menus compare with FileMaker menus, how to build a custom menu bar from scratch, and how to handle the Records menu — which is where found sets, record navigation, and deletion live. Together they form a complete picture of the menu layer.

If you are building your first 4D application, a reasonable order of operations is: define your tables, build your forms, then design the menu bar last, once you know which operations users actually need. The menu is the map; it should be drawn after you know the territory.

Frequently Asked Questions

Why can’t I rename a menu bar or a menu item in 4D?

Menu bars are permanently named Menu Bar #1, Menu Bar #2, and so on, and menu item labels are fixed at creation time. This is a deliberate constraint in the Menu Bar Editor rather than a bug. The practical workaround is to keep your own mapping document — a simple list pairing each numbered menu bar with its purpose — and to proofread item names before clicking Add Item, since the only correction path is delete-and-recreate.

Do I need a method attached to every menu item?

Functionally, yes, if you want the item to do anything. A menu item with no method appears in the menu and can be selected, but nothing happens. The exception is divider lines, which are structural rather than actionable. For items whose logic is not yet written, attach a stub method that displays a placeholder message, so the item is at least honest about its state.

Should the File menu include Import and Export in every application?

No. Include them when users genuinely move data in and out of the system — for example, receiving spreadsheet exports from a partner or handing query results to an analyst. If all data enters through your own forms and all output is printed or viewed on screen, Import and Export add surface area without adding value. Decide based on observed workflow, not on what other applications do.

How do I move a menu item down in the list?

You cannot drag an item downward directly. The Menu Bar Editor only lets you drag items up. To move an item down, drag the items above it upward past it, which effectively shifts it lower. Because dividers are items too, they follow the same rule. This is easiest to manage if you add items in your intended final order and only make small corrections afterward.

What is the difference between “Print Record” and “Print Found Set”?

“Print Record” prints the single record currently displayed, which suits form-style output such as an invoice or a customer profile. “Print Found Set” prints every record in the current selection, which suits list-style output such as a filtered report. Many applications include both, because users switch between the two modes depending on whether they are reviewing one item or a batch.

Can a menu item run cleanup code when the user quits?

Yes — this is one of the strongest reasons to include a Quit item rather than relying on users closing the application window. Attach a method to Quit that commits or cancels open transactions, releases record locks, closes windows in order, and optionally writes a session log. If Quit is absent from the menu, that method never runs, and the application shuts down in whatever state the user left it.