4th Dimension Learning Basics

The File Menu is arguably the single most important menu in any database application, and for that reason it almost always occupies the first position on the Menu Bar. It is the anchor users return to for the most fundamental operations — printing a record, exporting a found set, and quitting the application. When you design a custom menu set in 4D, the File Menu is where you establish the tone for the entire interface: is this a polished, purpose-built business application, or a thin wrapper around the development environment?

This article compares the File Menu across three environments: the FileMaker Pro (FMP) Browse Mode menu, the 4D Foundation (default) menu, and a 4D Custom Menu. The goal is not to copy one menu wholesale into another, but to understand why each item exists so you can decide what belongs in front of your users.

Key Takeaways

• The File Menu is the most important menu and conventionally sits first on the Menu Bar.
• Four items appear in all three File menus — Import, Export, Print, and Quit — because every user needs them.
• The default 4D Foundation File menu lacks a Page Setup option, which is a genuine usability gap.
• Development-oriented items (Define Fields, Define Value Lists, Access Privileges, etc.) should never appear in a user-facing custom menu.
• Open Database and Open Table are largely redundant in a 4D custom-menu environment, since 4D opens one database at a time.
• Log File / No Log File is a maintenance and backup concern and belongs in an administrator or program-specific menu, not the user’s File menu.

Why the File Menu Deserves Careful Design

A menu bar is a contract with the user. When someone clicks File, they expect a predictable set of operations that act on the document or dataset as a whole — not on a single field, not on the layout, and not on the database schema.

This convention is old and durable; it descends from the original Apple Human Interface Guidelines and is echoed in the menu structures of most desktop applications today. Violating it (for example, hiding Print under a custom menu, or putting schema-editing commands in File) forces users to hunt for basic functions and erodes trust in the application.

In 4D, menus are defined as menu bar objects and menu items, and they can be attached to forms and controlled dynamically through code. That flexibility is exactly why discipline matters: because you can put anything anywhere, you need a rationale for what goes where. The File Menu is the best place to start that discipline.

The Three Menus Under Comparison

The comparison below reflects the three environments discussed in this series. Note that the 4D Default Custom Menu is not shown in the original figure because its only menu item is Quit — a useful reminder that a “custom” menu set is only as good as the items you actually add to it.

Menu Item	FMP Browse Mode	4D Foundation (Default)	4D Custom Menu
New Database	Yes	—	—
Close	Yes	—	—
Define Fields	Yes	—	—
Define Value Lists	Yes	—	—
Access Privileges	Yes	—	—
Sharing	Yes	—	—
Save a Copy As	Yes	—	—
Recover	Yes	—	—
Import Records/Data	Yes	Yes	Yes
Export Records/Data	Yes	Yes	Yes
Print	Yes	Yes	Yes
Page Setup	Yes	—	Recommended
Quit	Yes	Yes	Yes
Open (Database)	Yes	—	—
Open Table	—	Yes	Optional
Preferences	—	Yes	—
Administration	—	Yes	—
Log File / No Log File	—	Yes	—

The pattern is clear: the FMP Browse Mode menu is crowded with schema and file-management commands because FileMaker historically exposed design tools through the same menu bar. The 4D Foundation menu is leaner but omits Page Setup. A well-built 4D Custom Menu sits between them — keeping the four universal items, restoring Page Setup, and deliberately excluding everything that belongs to the developer or the administrator.

Items That Should Not Appear in a User Menu

Several FMP Browse Mode items are excluded from this comparison because they let the user make design changes or perform functions that have no place in a 4D custom-menu environment. These are:

• New Database — creating a new database is a developer/administrator action, not a runtime user action.
• Close — in 4D, closing the database typically means quitting the application; a separate Close is confusing.
• Define Fields — schema editing. Never expose this to end users.
• Define Value Lists — value list maintenance is a design-time task.
• Access Privileges — security configuration belongs to the administrator.
• Sharing — network/sharing configuration is an administrative concern.
• Save a Copy As — file-level duplication is a maintenance operation.
• Recover — database recovery is a repair tool, not a user feature.

The underlying principle: anything that changes the structure of the database, its security, or its files on disk is an administrator function. A user-facing File Menu should contain only operations that act on data the user is legitimately working with.

The Four Universal Items — and Why They Matter

There are four menu items common to all three File menus: Import, Export, Print, and Quit. This is not coincidence. These four represent the complete lifecycle of getting data in, getting data out, producing a physical or PDF artifact, and ending the session. Any application that omits one of them will frustrate users.

• Import (Records/Data) — lets users bring external data (CSV, tab-delimited, or another database’s export) into a table. In 4D this maps naturally to import commands you can trigger from a menu item.
• Export (Records/Data) — the counterpart. Users frequently need to hand data to a spreadsheet or another system.
• Print — producing a record, a list, or a report. This is often the single most-used File command in a business app.
• Quit — ending the session cleanly, ideally with a confirmation and any necessary save/cleanup logic.

Because these four are so fundamental, they should be present, correctly labeled, and wired to sensible default behavior in every custom menu set you ship.

The Page Setup Gap

One thing genuinely lacking in the default 4D Foundation File menu is Page Setup. This is a real usability problem, not a cosmetic one. If a user cannot choose the page setup, the application silently reuses whatever page setup was last selected — which may be the wrong paper size, the wrong orientation, or the wrong margins for the report they are about to print.

The practical fix is straightforward: add a Page Setup menu item to your custom File Menu and attach it to the platform’s page setup dialog. Placing it directly above Print mirrors the convention users already know from other applications and gives them a chance to correct the layout before committing to a print job. For reports that must always print a specific way, you can still set the page setup programmatically at print time — but leaving the user a manual override is almost always the kinder choice.

Open Database, Open Table, and the Single-Database Reality

The FMP Open menu and the 4D User Open Database menu are not normally needed in a user/custom-menu environment. The reasoning is simple: by the time the user is looking at your menus, they have already opened the database. In 4D, moreover, you can only open one database at a time, so an “Open Database” command has no meaningful target — there is nothing else to switch to.

The Open Table item in the Foundation default menu is a different case. It can be useful, but it probably should not live in the File menu. Most well-designed applications give users another way to navigate between tables — a dedicated navigation menu, a toolbar, or buttons on a home form. Keeping table navigation out of File preserves the File menu’s meaning (document-level operations) and keeps navigation where users expect it.

If you do decide to expose table switching, consider a Go To or Navigate menu instead, and populate it dynamically from your table structure so it stays in sync as the schema evolves.

Preferences, Administration, and Log File

The Preferences and Administration items in the Foundation menu are, as the original notes, not really for the user — they are for an administrator. Preferences may include settings that affect the whole installation; Administration may expose user management, backups, or maintenance tasks. Exposing these to ordinary users invites accidental misconfiguration.

The Log File / No Log File user menu deserves special mention. It is used for database maintenance and database backup — toggling whether 4D writes a journal/log of data modifications. This is a serious operational setting: the log file is what allows a database to be recovered to a consistent state after an unexpected shutdown, and it interacts with your backup strategy. Turning it on or off casually from a user menu is risky.

The better design is to move log-file control into a program-specific menu (or an administrator-only menu) that is either hidden from regular users or protected by access privileges. If your application genuinely needs users to trigger a backup, expose a single, clearly labeled Backup command that runs a controlled routine — not a raw toggle of the logging mechanism.

How to Decide What Goes in Your File Menu

Use these criteria when you build or review a custom File Menu:

1. Does it act on the whole document/dataset? If yes, File is a candidate. If it acts on a field, a record, or a layout, it belongs elsewhere.
2. Is it a data operation or a schema/security/file operation? Data operations can be user-facing; schema, security, and file operations are administrative.
3. Does the user need it during normal work? Import, Export, Print, Page Setup, and Quit pass this test. Define Fields does not.
4. Is it redundant given 4D’s single-database model? Open Database fails this test.
5. Is it dangerous if misused? Log File toggling fails this test and belongs behind an administrator gate.
6. Is there a more natural home? Table navigation belongs in a navigation menu; maintenance belongs in an admin menu.

Applying these six questions consistently will produce a File Menu that is short, predictable, and trustworthy — which is exactly what the most important menu on the bar should be.

Frequently Asked Questions

Why is the File Menu always placed first on the Menu Bar?

Convention. Across virtually all desktop applications, the leftmost menu is reserved for document- and application-level operations, and users have decades of muscle memory expecting Print and Quit to be there. Placing File first reduces the cognitive load of learning your application and keeps it consistent with the platform’s own guidelines.

Which four items appear in all three File menus compared here?

Import, Export, Print, and Quit. These four cover the essential lifecycle of bringing data in, sending data out, producing a printed artifact, and ending the session, which is why they survive in every menu design regardless of environment.

Why is Page Setup missing from the default 4D Foundation File menu, and should I add it?

The Foundation menu simply does not include it, which means the application reuses whatever page setup was last chosen — potentially the wrong size, orientation, or margins. You should add a Page Setup item to your custom File Menu, ideally just above Print, so users can correct the layout before printing.

Why shouldn’t Open Database appear in a 4D custom menu?

Because 4D can only open one database at a time, and the user has already opened the database to reach your menus. An Open Database command has no meaningful target, so it is redundant in a user-facing custom menu.

Where should Log File / No Log File go instead of the user File menu?

It should move to a program-specific or administrator-only menu, because it controls journaling used for maintenance and backup and interacts with recovery. Exposing a raw logging toggle to ordinary users risks compromising recoverability; if users need backups, give them a single controlled Backup command instead.

Should Open Table stay in the File Menu?

Generally no. Table navigation is better handled by a dedicated navigation menu, a toolbar, or buttons on a home form, which keeps the File Menu focused on document-level operations and puts navigation where users expect to find it.