4. dimension læringsgrundlag
Forståelse af de faste menuer i 4D
Når du bygger en brugerdefineret applikation i 4D (4th Dimension), er en af de første ting, du opdager, at det ikke er alle dele af menulinjen, du har kontrol over. Menuerne Edit og Help er faste: De leveres af selve 4D-miljøet, de optræder i enhver kompileret og fortolket applikation, og deres menupunkter kan ikke omdøbes, omorganiseres eller fjernes via den standard menu-editor.
Dette overrasker udviklere, der kommer fra FileMaker Pro, hvor menusystemet er sammenlignningsvis åbent, og hvor man ofte kan undertrykke eller erstatte store dele af standardmenulinjen. I 4D reserverer platformen en lille, men vigtig del af brugerfladen til sig selv. At forstå hvorfor disse menuer er faste — og hvad du stadig kan gøre omkring dem — er en central del af at mestre 4D.
Figur 10 i den oprindelige lektion viser 4D’s “Edit”- og “Help”-menuer side om side. Lektionens pointe er simpel og værd at gentage: alle programmer vil have disse menuer og menupunkter. Du kan ikke fravælge dem. Det, du kan gøre, er at designe resten af din menulinje, så de faste menuer føles som en naturlig del af din applikation fremfor en forstyrrelse.
Hvorfor 4D reserverer Edit- og Help-menuerne
De faste menuer eksisterer, fordi 4D er både et udviklingsmiljø og en runtime. Den samme menumekanisme, som giver dig mulighed for at redigere en metode i Design-miljøet, skal også kunne håndtere tekstindtastning i et felt i en formular under runtime. Edit-menuen indeholder de standardkommandoer til udklipsholder og tekstredigering — Fortryd (Undo), Klippe (Cut), Kopiere (Copy), Sætte ind (Paste), Slet (Clear), Marker alt (Select All) — som brugere forventer i ethvert tekstfelt, uanset om feltet er et 4D-dataindtastningsområde, et kommentarfelt eller en søgelinje.
Help-menuen er derimod platformens indgang til dens egen dokumentation, “Om”-information og versionsrapportering. Da 4D leveres som én samlet engine på tværs af fortolkede og kompilerede tilstande, og på tværs af Windows og macOS, beholder leverandøren kontrollen over disse to menuer for at garantere en ensartet adfærd, uanset hvad udvikleren gør.
Dette medfører et par praktiske konsekvenser:
Related: — A spreadsheet-simple interface sitting on top of a real , with automations, views, and shareable interfaces..
- Du kan ikke slette dem. Det er ikke understøttet at forsøge at fjerne Edit eller Help fra menulinjen. Kommando-sættet til menulinjen i 4D arbejder med de menuer, du definerer; de faste menuer ligger uden for dette område.
- Du kan ikke omdøbe deres punkter. “Undo”, “Paste” og “Select All” vil altid fremstå således (afhængigt af operativsystemets sprog).
- Deres adfærd er knyttet til det fokuserede objekt. Punkterne i Edit-menuen aktiveres og deaktiveres automatisk afhængigt af, om et tekstindtastningsobjekt har fokus. Dette er en funktion, ikke en begrænsning — det betyder, at du får korrekt udklipsholder-adfærd i hvert eneste indtastningsfelt helt gratis.
- De optræder i begge tilstande. Både fortolkede (Design/User) og kompilerede (merged) applikationer viser dem.
Konklusionen for en “citizen developer” eller et lille udviklingsteam er, at du bør betragte Edit og Help som platformens inventar. Design omkring dem i stedet for at kæmpe imod dem.
Hvordan de faste menuer interagerer med dine brugerdefinerede menuer
Den oprindelige lektion er en del af en større sekvens om menuer: sammenligning af FileMaker Pro- og 4D-menuer, opbygning af en brugerdefineret 4D-menu, og derefter gennemgang af sammenligninger mellem File, Records og “andre” menuer. Diskussionen om Edit/Help falder under kategorien “andre” — de menuer, du ikke selv kan forfatte.
Det vigtige designspørgsmål er rækkefølge og gruppering. I 4D bygger du din brugerdefinerede menulinje med kommandoer som INSERT MENU, APPEND MENU ITEM og lignende, og du knytter linjen til en formular eller til applikationen. De faste menuer indtager konventionelle positioner:
If you are shopping: — A that plugs into the wider Zoho suite and prices per user rather than per app..
- Edit placeres typisk efter File og eventuelle brugerdefinerede menuer, du indsætter i starten.
- Help placeres konventionelt yderst til højre på menulinjen på både Windows og macOS.
Da du ikke kan flytte dem, er den praktiske vejledning at placere dine egne menuer således, at de faste menuer lander der, hvor brugerne forventer dem. Hvis du indsætter en “Records”-menu og en “Reports”-menu, så overvej, om Edit skal ligge imellem dem eller efter dem. De fleste brugere har en stærk muskelhukommelse for, at Help er sidst, og Edit er placeret et sted i området fra venstre mod midten. Respekter dette.
En nyttig mental model er at se menulinjen som en kontrakt:
| Område | Hvem kontrollerer det | Hvad hører til her |
|---|---|---|
| File | Dig (kan tilpasses) | Ny, Åbn, Gem, Udskriv, Afslut-agtige handlinger |
| Edit | 4D (fast) | Fortryd, Klippe, Kopiere, Sætte ind, Slet, Marker alt |
| Records | Dig (kan tilpasses) | Navigation, opret/slet post, søgning |
| Brugerdefinerede menuer | Dig | Din apps domænespecifikke handlinger |
| Help | 4D (fast) | Platform-hjælp, Om, versionsinfo |
Hvis du holder dine brugerdefinerede menuer i “dig”-rækkerne og lader de faste rækker være i fred, vil din menulinje føles naturlig for enhver, der tidligere har brugt en desktop-applikation.
Hvad du stadig kan tilpasse omkring dem
At menuerne er faste, betyder ikke, at menulinjen er fastlåst. Der er meget, du kontrollerer, og ved at kende grænsen kan du bruge din indsats der, hvor det gør en forskel.
- Dine egne menuer på øverste niveau. Fil, Optegnelser og eventuelle domænespecifikke menuer (Rapporter, Hjælpeprogrammer, Admin) er dine til at definere, navngive og udfylde.
- Menupunkter og undermenuer. Du kan tilføje elementer, separatorer, flueben, tastaturgenveje og indlejrede undermenuer i dine menuer.
- Aktiver/deaktiver-logik. Du kan gråne dine egne elementer ud kontekstuelt –for eksempel ved at deaktivere “Slet post”, når ingen post er valgt – ved hjælp af 4D’s kommandoer til menupunkters tilstand.
- Kontekstmenuer. Højrekliksmenuer (kontekstuelle) er en separat mekanisme fra menulinjen og er fuldstændig under din kontrol, så de er et godt sted at placere handlinger, der ellers ville rode i den faste bjælke.
- Om/Hjælp-oplevelsen. Selvom du ikke kan omskrive Hjælp-menuens indbyggede elementer, kan du tilføje din egen “Om MyApp”- eller “Dokumentation”-kommando inde i en af dine brugerdefinerede menuer, hvilket giver brugerne en brandet sti til dit hjælpeindhold.
Mønsteret, der fungerer godt: Hold de faste menuer slanke og urørte, og diriger al applikationsspecifik hjælp og “om”-information gennem dine egne menupunkter. På den måde forbliver platformens Hjælp-menu som flugtvejen til 4D’s egen dokumentation, og dine brugere finder stadig dit materiale.
Praktisk vejledning: Design af en menulinje, der sameksisterer med faste menuer
Når du sætter dig ned for at udforme menulinjen for en ny 4D-applikation, skal du arbejde dig igennem disse beslutninger i rækkefølge:
- List de verber, dine brugere har brug for. Opret, find, rediger, slet, udskriv, eksporter, naviger, administrer. Gruppér dem efter navneord.
- Kort hver gruppe til en menu på øverste niveau. Optegnelser, Rapporter, Hjælpeprogrammer og så videre.
- Reserver de konventionelle pladser. Lad Fil føre an, lad Rediger sidde på sin naturlige plads, og lad Hjælp lukke bjælken.
- Beslut, hvad der skal i kontekstmenuer. Alt, der kun er relevant for et valgt objekt (en række, et felt, en post), er ofte bedre som en højreklikshandling end som et element i menulinjen.
- Planlæg aktiver/deaktiver-regler. Spørg for hvert brugerdefineret element: “Hvornår skal dette være grånet ud?”, og implementer den logik tidligt i stedet for at eftermontere den.
- Test i begge tilstande. Bekræft, at menulinjen opfører sig korrekt i både fortolkede og kompilerede builds, og på både Windows og macOS, hvis du udgiver på tværs af platforme.
En almindelig fejl blandt udviklere, der er nye til 4D, er at prøve at replikere Rediger-menuens funktioner inde i en brugerdefineret menu – ved at tilføje deres egne “Kopiér”- og “Sæt ind”-punkter. Dette skaber duplikerede kommandoer, forvirrer brugerne og fungerer normalt dårligere end de indbyggede elementer, fordi platformens versioner allerede er koblet til det fokuserede tekstobjekt. Genopfind ikke de faste menuer; suppler dem.
En anden fejl er at begrave kritiske handlinger så dybt i brugerdefinerede undermenuer, at brugerne aldrig finder dem, mens de faste Rediger- og Hjælp-menuer sidder fremtrædende i kanterne. Brug den visuelle vægt af de faste menuer som et anker: Placer dine mest brugte kommandoer i menuer på øverste niveau i nærheden af dem, ikke tre niveauer nede.
Hvordan dette adskiller sig fra FileMaker Pro
Den originale lektion indrammer eksplicit dette afsnit som en del af en sammenligning mellem FileMaker Pro og 4D, og punktet om Rediger/Hjælp er en af de tydeligste forskelle. FileMaker Pro giver udviklere et forholdsvis åbent menusystem – du kan bygge brugerdefinerede menuer, og med den relevante konfiguration kan du skjule eller erstatte store dele af standardmenulinjen. 4D tager en mere konservativ holdning: Et defineret sæt platformsmenuer er altid til stede.
Ingen af tilgangene er objektivt bedre; de afspejler forskellige filosofier.
- FileMakers fleksibilitet passer til udviklere, der ønsker total kontrol over brugerens visuelle miljø og er villige til at tage ansvar for at levere hver eneste kommando, brugeren har brug for.
- 4D’s faste menuer garanterer, at standard tekstredigering og platformshjælp altid er tilgængelig, hvilket reducerer risikoen for, at en bruger går i stå i et felt uden mulighed for at indsætte tekst, eller i en app uden vej til dokumentation.
For en udvikler i et lille team er 4D’s holdning ofte den nemmeste at leve med, fordi den fjerner en hel kategori af beslutninger. Du behøver aldrig at spørge: “Skal jeg lave min egen Kopiér-kommando?” – svaret er allerede nej.
Key Takeaways
- Menuerne Rediger og Hjælp i 4D er faste: De vises i alle applikationer, og deres elementer kan ikke omdøbes, omarrangeres eller fjernes.
- De eksisterer, fordi 4D både er et udviklingsmiljø og en runtime, og platformen har brug for garanteret udklipsholder- og hjælpeadfærd i hvert tekstfelt.
- Du styrer stadig Fil, Optegnelser og alle dine egne brugerdefinerede menuer, samt kontekstmenuer og aktiver/deaktiver-logik.
- Design omkring de faste menuer: Placer dine brugerdefinerede menuer, så Rediger og Hjælp lander, hvor brugerne forventer dem, og dupliker aldrig de indbyggede udklipsholder-kommandoer.
- Diriger din egen “Om” og dokumentation gennem brugerdefinerede menupunkter i stedet for at prøve at ændre Hjælp-menuen.
- Dette er en vigtig kontrast til FileMaker Pro, som giver udviklere langt mere kontrol over menulinjen.
Ofte stillede spørgsmål
Kan jeg fjerne menuen Rediger eller Hjælp fra en 4D-applikation?
Nej. Disse menuer leveres af 4D-miljøet og er til stede i enhver applikation, uanset om den er fortolket eller kompileret. De menukommandoer, du bruger til at bygge en brugerdefineret menulinje, opererer på de menuer, du selv definerer, ikke på platformens faste menuer. Den praktiske tilgang er at designe dine egne menuer, så de faste menuer befinder sig i deres konventionelle positioner.
Hvorfor holder 4D menuen Rediger fast i stedet for at lade udviklere tilpasse den?
Fordi 4D fungerer både som et udviklingsmiljø og en runtime, har platformen brug for pålidelig adfærd for udklipsholder og tekstredigering i hvert tekstinputobjekt. Ved at holde Fortryd, Klip, Kopier, Indsæt, Ryd og Vælg alt under sin egen kontrol, garanterer 4D, at disse kommandoer fungerer korrekt og konsekvent, uanset hvad udvikleren bygger, og på tværs af Windows og macOS.
Skal jeg oprette mine egne Copy and Paste menupunkter?
Generelt nej. De indbyggede menupunkter i Rediger-menuen er allerede forbundet til det fokuserede tekstobjekt og aktiveres eller deaktiveres automatisk. Tilføjelse af dine egne dubletter skaber forvirring og fungerer normalt dårligere. Brug i stedet din indsats med menudesign på domænespecifikke kommandoer, som platformen ikke tilbyder.
Hvor skal mine brugerdefinerede menuer placeres i forhold til de faste?
Følg skrivebordskonventionerne: Lad File føre bjælken, lad Edit sidde i sin naturlige position fra venstre mod midten, og lad Help lukke bjælken til højre. Indsæt dine egne menuer — Records, Reports, Utilities — så de grupperes logisk uden at skubbe de faste menuer hen på uventede steder. Brugere stoler på muskelhukommelsen for, hvor Edit og Help befinder sig.
Kan jeg tilføje min egen “Om”- eller hjælpekommando, hvis Hjælp-menuen er fast?
Ja — bare ikke inde i selve Hjælp-menuen. Tilføj et “Om MyApp”- eller “Dokumentation”-punkt til en af dine egne brugerdefinerede menuer. Dette giver brugerne en brandet vej til dit hjælpeindhold, mens platformens Hjælp-menu forbliver intakt som ruten til 4D’s egen dokumentation.
Er adfærden for de faste menuer forskellig mellem fortolkede og kompilerede 4D-applikationer?
Rediger- og Hjælp-menuerne vises i begge tilstande, så begrænsningen er den samme, uanset om du kører i Design-/Bruger-miljøet eller leverer en flettet, kompileret applikation. Det, der ændrer sig mellem tilstandene, er anden adfærd — debugging, metodeadgang og så videre — men de faste menuer forbliver faste hele vejen igennem.
P.S. A few readers have asked which relational database platform we actually reach for — it's Claris FileMaker Pro; if you want the current details.
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.
Try FileMaker Free for 45 Days
The long-running relational database platform for teams that need custom apps on desktop, web, and mobile from a single file.