4th Dimension Learning Basics

Why the Records Menu Is the First Custom Menu You Should Build

When you move from a stock 4D menu bar to a custom one, the Records menu is the natural starting point. It touches the operations that nearly every database user performs dozens of times a day — creating a record, finding one, sorting a list, switching between list and form views. Get this menu right and the rest of your custom menu bar tends to fall into place, because the Records menu establishes the patterns (grouping, separators, shortcuts) you will reuse for File, Edit, and any domain-specific menus you add later.

This article walks through building the Records menu in the 4D Menu Bar Editor, explains how keyboard shortcuts actually work in 4D (which surprises almost everyone the first time), and gives you the practical judgment calls — which items belong, which shortcuts to avoid, and how to keep your menu bar maintainable as the application grows.

Key Takeaways

• The Records menu is the recommended first custom menu because its commands are universal across most databases.
• Group related items with separator lines: record creation, navigation, search, sort, and view switching.
• 4D creates keyboard shortcuts through the Menu Bar Editor’s Shortcut option — you do not type the Command (⌘) symbol yourself.
• Create the menu item’s name first, then set its shortcut; menu items cannot be edited after creation, so a mis-ordered workflow forces a delete-and-recreate.
• Several shortcuts are reserved by the operating system and by 4D itself (⌘C, ⌘V, ⌘X, ⌘Z, ⌘Q, ⌘W, and ⌘. on Mac; the Control equivalents on Windows).
• A menu item with a shortcut but no assigned method does nothing when invoked — wiring methods is a separate step.

The Recommended Records Menu Structure

The original guidance proposes a specific set of items. Here is that structure, expanded with the reasoning behind each grouping:

Record creation and deletion

• New — creates a new record in the current table.
• Duplicate — copies the current record, useful for template-style data entry.
• Delete — removes the current record (and, in most designs, should prompt for confirmation).

Record navigation

• Next, Previous, First, Last — move the current record pointer through the selection.

Search and selection

• Find — opens the standard query editor.
• Find by Formula — lets power users write a query expression directly.
• Show All — clears the current selection and displays every record.
• Show Omitted — inverts the selection, showing only the records that were excluded.

Ordering

• Sort — applies a sort order to the current selection.

View switching

• List View — the multi-record grid.
• Form View — the single-record detail layout.

Separator lines (created by adding an item and choosing the Line option) divide these into logical clusters. That visual rhythm matters more than it sounds: users scan menus by shape and position, not by reading every label. A menu with five clean groups is faster to use than a flat list of fifteen commands.

A Structured Way to Decide What Belongs

Not every database needs every item. Use these criteria when trimming or extending the list:

Criterion	Include the item if…	Consider omitting if…
Frequency	Users invoke it daily	It is a rare administrative action
Risk	It is safe or confirmable	It silently destroys data with no undo
Discoverability	Users would not find it elsewhere	It already lives on a toolbar or button
Consistency	It matches platform conventions	It duplicates a reserved OS shortcut
Scope	It applies to the current table generally	It is specific to one form or workflow

The last row is the important one. A Records menu should hold generic record operations. If a command only makes sense inside one particular data-entry screen, it belongs on that screen — as a button or a form-specific menu — not in the global Records menu.

Creating the Menu and Its Items

The procedure mirrors the one used for the File menu:

1. Open the Menu Bar Editor from the Design environment (Design → Tools menu).
2. Select New Menu and type Records as the menu name.
3. Add each menu item with Add Item, typing the item’s name.
4. Insert separator lines by adding an item and selecting the Line option.
5. Assign shortcuts to the items that warrant them (see below).
6. Assign methods to each item so the command actually does something.

Step 6 is the one people forget. A menu item is only a label and a shortcut until a method is attached to it. In 4D, menu items are wired to methods through the menu item’s properties — typically a project method that performs the corresponding record operation. Until that method exists and is assigned, clicking the item or pressing its shortcut produces nothing.

How Keyboard Shortcuts Really Work in 4D

This is the part that trips up newcomers, and the original article is right to flag it.

The instinct is to type something like New N to get a ⌘N shortcut. That does not work. The Command symbol (⌘) is not a character you type into the item name — and while a Chicago-font Control-Q trick works in some word processors, it does not work in 4D for creating shortcuts.

Instead, 4D makes it genuinely simple:

1. Open the Menu Bar Editor.
2. Select the menu you want.
3. Create a new menu item and type its name.
4. Click the Shortcut option and enter the shortcut character that will be paired with the Command symbol (on Macintosh) or Control (on Windows).

That is the whole process. 4D handles the platform-specific modifier for you, which is a real convenience: the same menu definition produces ⌘-based shortcuts on macOS and Ctrl-based shortcuts on Windows without you maintaining two sets of definitions.

The Order-of-Operations Trap

There is a strict sequence, and violating it wastes time:

• Create the menu item first by typing its name.
• Then set the shortcut.

Menu items cannot be modified after creation. If you add a new item, jump straight to the Shortcut field, and then try to go back and type the name, you will find the name field will not accept input. The fix is to delete the blank item and create it again, this time in the correct order. It is a small annoyance, but it catches nearly everyone once.

Reserved Shortcuts You Must Avoid

Both the operating system and 4D itself claim certain combinations. The 4D Design Reference Manuals list the following as reserved:

Mac Keys	Windows Keys	Operation
⌘C	Ctrl C	Copy
⌘Q	Ctrl Q	Quit
⌘V	Ctrl V	Paste
⌘X	Ctrl X	Cut
⌘Z	Ctrl Z	Undo
⌘.	Ctrl . (period)	Stop action
⌘W	Ctrl W	Flushes records to disk in User or Custom Menus environments

Two of these deserve emphasis. ⌘Q / Ctrl Q is the application quit command — reassigning it will confuse and frustrate users who expect it to close the app. ⌘W / Ctrl W is subtler: in User and Custom Menus environments it flushes records to disk, which is a data-integrity operation, not a window-closing operation. Overriding it can put unsaved data at risk.

The practical rule: before assigning any shortcut, check it against this table. When in doubt, choose a less obvious letter rather than fight the platform.

Choosing Shortcuts That Scale

A few judgment calls that pay off as your application grows:

• Reserve the obvious letters for the most frequent commands. New, Find, and Sort are the natural candidates for single-letter shortcuts.
• Keep a mental (or written) registry. As you add File, Edit, and domain menus, you will accumulate shortcuts fast. A simple table in your project documentation prevents collisions.
• Prefer mnemonics over arbitrary letters. ⌘D for Duplicate, ⌘F for Find, ⌘S for Sort — these are memorable and reduce training time.
• Do not shortcut everything. A menu crowded with shortcuts is harder to scan. Shortcut the top handful of commands and let the rest be menu-only.
• Remember the modifier is automatic. You specify the character; 4D maps it to ⌘ on Mac and Ctrl on Windows. Do not try to encode the modifier yourself.

From Menu to Working Command

The finished Records menu — with its grouped items, separator lines, and shortcuts — is only the visible half of the work. The other half is the methods behind each item.

A sensible build order:

1. Define the menu structure (names, groups, separators).
2. Assign shortcuts to the high-frequency items.
3. Write or attach the methods that perform each operation.
4. Test on both platforms if you ship to Mac and Windows, confirming that shortcuts behave as expected and that no reserved combination was accidentally claimed.
5. Document the menu so the next developer (or future you) knows which shortcuts are taken.

For readers coming from other database platforms, it is worth noting that 4D’s menu model is closer to a traditional compiled application than to the ribbon-and-toolbar conventions popularized by Microsoft Access. If you are migrating from FileMaker Pro, expect the menu-building workflow to feel different — 4D gives you a genuine Menu Bar Editor rather than a scripted menu step, and the shortcut mechanism described above is specific to 4D. The broader concept of a menu bar as a structured command surface is common to desktop application design across platforms; see the Wikipedia article on menu bars for the general model.

Common Mistakes and How to Avoid Them

• Creating the item in the wrong order. Name first, shortcut second. Always.
• Assigning a reserved shortcut. Check the reserved table before every assignment.
• Leaving items unwired. A menu item with no method is a dead command. Test each one.
• Overloading the Records menu. Keep it generic; push form-specific commands onto forms.
• Forgetting separators. Ungrouped menus slow users down.
• No shortcut registry. Collisions creep in as the menu bar grows.

Frequently Asked Questions

Why should the Records menu be the first custom menu I build?

Because its commands — New, Find, Sort, navigation, view switching — are common to almost every database, so the menu delivers immediate value and establishes the grouping and shortcut patterns you will reuse for every other menu. Building it first also surfaces the shortcut-ordering quirk early, before you have many menus to fix.

How do I create a Command-key shortcut in 4D?

Open the Menu Bar Editor, create the menu item and type its name, then click the Shortcut option and enter the character that will be paired with the Command symbol (Macintosh) or Control (Windows). You never type the ⌘ symbol itself — 4D applies the correct platform modifier automatically.

Why can’t I type a name into my new menu item?

Because menu items cannot be modified after creation. If you add an item, go to the Shortcut field, and then return to the name, the name field will not accept input. Delete the blank item and recreate it, typing the name first and setting the shortcut second.

Which keyboard shortcuts should I avoid?

Avoid the reserved combinations listed in the 4D Design Reference Manuals: ⌘C/Ctrl C (Copy), ⌘Q/Ctrl Q (Quit), ⌘V/Ctrl V (Paste), ⌘X/Ctrl X (Cut), ⌘Z/Ctrl Z (Undo), ⌘./Ctrl . (Stop action), and ⌘W/Ctrl W (flushes records to disk in User or Custom Menus environments). Overriding these confuses users and, in the case of ⌘W, can risk unsaved data.

Do menu items work as soon as I create them?

No. A menu item is just a label and an optional shortcut until you assign a method to it. You must write or attach the method that performs the operation; otherwise clicking the item or pressing its shortcut does nothing.

Can I use the same menu definition on both Mac and Windows?

Yes. That is one of the advantages of 4D’s shortcut mechanism — you specify the character, and 4D maps it to ⌘ on Macintosh and Ctrl on Windows. You still need to test on both platforms, since reserved combinations and user expectations differ between them.

Where to Go Next

With the Records menu built and wired, the same procedure extends naturally to the other menus in your custom menu bar. The File menu follows the pattern you already established; Edit and any domain-specific menus come after.

Keep the reserved-shortcut table handy, maintain a shortcut registry, and test each item as you wire it. The result is a menu bar that feels like a purpose-built application rather than a generic database shell — which is exactly the impression a well-designed 4D solution should give.