4. dimensjon læringsgrunnleggende

Forstå de faste menyene i 4D

Når du bygger en tilpasset applikasjon i 4D (4th Dimension), er en av de første tingene du oppdager at ikke alle deler av menylinjen er under din kontroll. Menyene Rediger (Edit) og Hjelp (Help) er faste: de leveres av selve 4D-miljøet, de vises i alle kompilerte og tolkede applikasjoner, og menyelementene deres kan ikke gis nytt navn, omorganiseres eller fjernes gjennom den standard menyredigeringen.

Dette overrasker utviklere som kommer fra FileMaker Pro, hvor menysystemet er relativt åpent og hvor du ofte kan undertrykke eller erstatte store deler av standardmenylinjen. I 4D reserverer plattformen en liten, men viktig del av grensesnittet for seg selv. Å forstå hvorfor disse menyene er faste – og hva du fortsatt kan gjøre rundt dem – er en kjernedel av 4D-kunnskap.

Figur 10 i den originale leksjonen viser 4D-menyene “Rediger” og “Hjelp” side om side. Leksjonens poeng er enkelt og verdt å gjenta: alle programmer vil ha disse menyene og menyelementene. Du får ikke velge dem bort. Det du kan gjøre, er å designe resten av menylinjen din slik at de faste menyene føles som en naturlig del av applikasjonen din i stedet for en inntrenging.

Hvorfor 4D reserverer Rediger- og Hjelp-menyene

De faste menyene eksisterer fordi 4D både er et utviklingsmiljø og en kjøretid (runtime). Den samme menymekanismen som lar deg redigere en metode i designmiljøet, må også håndtere tekstinntasting i et skjemafelt under kjøring. Rediger-menyen inneholder standard kommandoer for utklippstavle og tekstredigering – Angre, Klipp ut, Kopier, Lim inn, Slett, Velg alt – som brukere forventer i ethvert tekstfelt, enten det er et 4D-datafelt, en kommentarboks eller et søkefelt.

Hjelp-menyen er på sin side plattformens kobling til egen dokumentasjon, “Om”-informasjon og versjonsrapportering. Fordi 4D leveres som én enkelt motor på tvers av tolkede og kompilerte moduser, og på tvers av Windows og macOS, beholder leverandøren disse to menyene under egen kontroll for å garantere konsistent oppførsel uavhengig av hva utvikleren gjør.

Noen praktiske konsekvenser følger av dette:

Related: Airtable — A spreadsheet-simple interface sitting on top of a real relational database, with automations, views, and shareable interfaces..

• Du kan ikke slette dem. Forsøk på å fjerne Edit eller Help fra menylinjen støttes ikke. Menylinjekommandosettet i 4D fungerer med menyene du definerer; de faste menyene ligger utenfor dette omfanget.
• Du kan ikke gi elementene deres nytt navn. “Angre”, “Lim inn” og “Velg alt” vil alltid stå slik (avhengig av operativsystemets språk).
• Oppførselen deres er knyttet til det fokuserte objektet. Elementene i Rediger-menyen aktiveres og deaktiveres automatisk avhengig av om et tekstfelt har fokus. Dette er en funksjon, ikke en begrensning – det betyr at du får korrekt utklippstavle-oppførsel i hvert inntastingsfelt gratis.
• De vises i begge moduser. Både tolkede (Design/Bruker) og kompilerte (sammenslåtte) applikasjoner viser dem.

Konklusjonen for en «citizen developer» eller en utvikler i et lite team, er at du bør behandle Edit og Help som plattformmøbler. Design rundt dem i stedet for å kjempe mot dem.

Hvordan de faste menyene samhandler med dine egendefinerte menyer

Den originale leksjonen er en del av en større sekvens om menyer: sammenligning av FileMaker Pro- og 4D-menyer, bygging av en tilpasset 4D-meny, og deretter gjennomgang av sammenligninger mellom Fil, Poster og “andre” menyer. Diskusjonen om Rediger/Hjelp tilhører kategorien “annet” – menyene du ikke får utforme selv.

Det viktige designspørsmålet er rekkefølge og gruppering. I 4D bygger du din egendefinerte menylinje med kommandoer som INSERT MENU, APPEND MENU ITEM og lignende, og du fester linjen til et skjema eller til applikasjonen. De faste menyene opptar konvensjonelle posisjoner:

If you are shopping: Zoho Creator — A low-code app builder that plugs into the wider Zoho suite and prices per user rather than per app..

• Rediger (Edit) ligger vanligvis etter Fil (File) og eventuelle egendefinerte menyer du setter inn helt i starten.
• Hjelp (Help) ligger konvensjonelt helt til høyre på menylinjen på både Windows og macOS.

Fordi du ikke kan flytte dem, er den praktiske veiledningen å plassere dine egne menyer slik at de faste menyene havner der brukerne forventer dem. Hvis du setter inn en “Poster”-meny og en “Rapporter”-meny, tenk over om Rediger bør ligge mellom dem eller etter dem. De fleste brukere har en sterk forventning basert på muskelminne om at Hjelp er sist og Rediger er et sted i området fra venstre til midten. Respekter dette.

En nyttig mental modell er menylinjen som en kontrakt:

Region	Hvem kontrollerer den	Hva hører hjemme der
Fil	Du (tilpassbar)	Ny, Åpne, Lagre, Skriv ut, Avslutt-lignende handlinger
Rediger	4D (fast)	Angre, Klipp ut, Kopier, Lim inn, Slett, Velg alt
Poster	Du (tilpassbar)	Navigering, opprett/slett post, søk
Egendefinerte menyer	Du	Appens domenespesifikke handlinger
Hjelp	4D (fast)	Plattformhjelp, Om, versjonsinformasjon

Hvis du holder dine egendefinerte menyer i “du”-radene og lar de faste radene være i fred, vil menylinjen føles naturlig for alle som har brukt en skrivebordsapplikasjon før.

Hva du fortsatt kan tilpasse rundt dem

At menyene er faste betyr ikke at menylinjen er låst. Det er mye du kontrollerer, og ved å kjenne grensen kan du bruke innsatsen din der den teller mest.

• Dine egne menyer på øverste nivå. Fil, Poster og eventuelle domenespesifikke menyer (Rapporter, Verktøy, Admin) kan du definere, navngi og fylle ut.
• Menyelementer og undermenyer. Du kan legge til elementer, skilletegn, hakemerker, tastatursnarveier og nestede undermenyer i menyene dine.
• Aktiver/deaktiver-logikk. Du kan grå ut dine egne elementer kontekstuelt – for eksempel deaktivere “Slett post” når ingen post er valgt – ved å bruke 4Ds kommandoer for menyelementstatus.
• Kontekstmenyer. Høyreklikkmenyer (kontekstmenyer) er en separat mekanisme fra menylinjen og er fullstendig under din kontroll, så de er et godt sted å plassere handlinger som ellers ville rotet til den faste linjen.
• Om/Hjelp-opplevelsen. Selv om du ikke kan omskrive hjelpemenyens innebygde elementer, kan du legge til din egen “Om MyApp”- eller “Dokumentasjon”-kommando inne i en av de egendefinerte menyene dine, slik at brukerne får en merkevarebyggende vei til hjelpeinnholdet ditt.

Mønsteret som fungerer bra: hold de faste menyene slanke og urørte, og rut all applikasjonsspesifikk hjelp og “om”-informasjon gjennom dine egne menyelementer. På den måten forblir plattformens hjelpemeny som fluktluken til 4Ds egen dokumentasjon, mens brukerne dine fortsatt finner ditt materiale.

Praktisk veiledning: Utforming av en menylinje som eksisterer sammen med faste menyer

Når du setter deg ned for å legge ut menylinjen for en ny 4D-applikasjon, bør du gå gjennom disse beslutningene i denne rekkefølgen:

Related: Knack — A no-code database builder aimed at portals, directories, and internal tools — with flat-rate pricing instead of per-user fees..

1. List opp verbene brukerne dine trenger. Opprett, finn, rediger, slett, skriv ut, eksporter, naviger, administrer. Grupper dem etter substantiv.
2. Knytt hver gruppe til en meny på øverste nivå. Poster, Rapporter, Verktøy, og så videre.
3. Reserver de konvensjonelle plassene. La File lede an, la Edit sitte på sin naturlige plass, og la Help avslutte linjen.
4. Bestem hva som skal i kontekstmenyer. Alt som bare er relevant for et valgt objekt (en rad, et felt, en post) er ofte bedre som en høyreklikkhandling enn som et element i menylinjen.
5. Planlegg regler for aktivering/deaktivering. For hvert tilpasset element, spør “når skal dette være grået ut?” og implementer denne logikken tidlig i stedet for å ettermontere den.
6. Test i begge moduser. Kontroller at menylinjen oppfører seg riktig i både tolkede og kompilerte bygg, og på både Windows og macOS hvis du leverer på tvers av plattformer.

En vanlig feil blant utviklere som er nye i 4D, er å prøve å replikere Edit-menyens funksjoner i en egendefinert meny – ved å legge til egne “Kopier”- og “Lim inn”-elementer. Dette skaper dupliserte kommandoer, forvirrer brukerne, og fungerer vanligvis dårligere enn de innebygde elementene fordi plattformens versjoner allerede er koblet til det fokuserte tekstobjektet. Ikke gjenoppfinn de faste menyene; utfyll dem.

En annen feil er å begrave kritiske handlinger så dypt i egendefinerte undermenyer at brukerne aldri finner dem, mens de faste Edit- og Help-menyene sitter fremtredende i kantene. Bruk den visuelle vekten til de faste menyene som et anker: legg de mest brukte kommandoene dine i menyer på øverste nivå i nærheten av dem, ikke tre nivåer ned.

Hvordan dette skiller seg fra FileMaker Pro

Den opprinnelige leksjonen rammer eksplisitt inn denne delen som en del av en sammenligning mellom FileMaker Pro og 4D, og punktet om Edit/Help er et av de tydeligste avvikene. FileMaker Pro gir utviklere et relativt åpent menysystem – du kan bygge egendefinerte menyer, og med riktig konfigurasjon kan du skjule eller erstatte store deler av standardmenylinjen. 4D har en mer konservativ holdning: et definert sett med plattformmenyer er alltid til stede.

Our pick: Claris FileMaker Pro — The long-running relational database platform for teams that need custom apps on desktop, web, and mobile from a single file..

Ingen av tilnærmingene er objektivt sett bedre; de reflekterer ulike filosofier.

• FileMakers fleksibilitet passer utviklere som ønsker total kontroll over brukerens visuelle miljø og er villige til å ta ansvar for å tilby hver eneste kommando brukeren trenger.
• 4Ds faste menyer garanterer at standard tekstredigering og plattformhjelp alltid er tilgjengelig, noe som reduserer sjansen for at en bruker blir sittende fast i et felt uten mulighet til å lime inn, eller i en app uten vei til dokumentasjon.

For en utvikler i et lite team er 4Ds holdning ofte den enkleste å leve med, fordi den fjerner en hel kategori av beslutninger. Du trenger aldri å spørre “bør jeg tilby min egen Kopier-kommando?” – svaret er allerede nei.

Viktige takeaways

• Edit- og Help-menyene i 4D er faste: de vises i alle applikasjoner, og elementene deres kan ikke gis nytt navn, omorganiseres eller fjernes.
• De eksisterer fordi 4D er både et utviklingsmiljø og en kjøretid, og plattformen trenger garantert utklippstavle- og hjelpeadferd i hvert tekstfelt.
• Du kontrollerer fortsatt File, Records og alle dine egne tilpassede menyer, pluss kontekstmenyer og aktiver/deaktiver-logikk.
• Design rundt de faste menyene: Plasser de tilpassede menyene dine slik at Edit og Help lander der brukerne forventer dem, og dupliser aldri de innebygde utklippstavlekommandoene.
• Rut din egen “Om”-informasjon og dokumentasjon gjennom egendefinerte menyelementer i stedet for å prøve å endre Help-menyen.
• Dette er en sentral kontrast til FileMaker Pro, som gir utviklere langt mer kontroll over menylinjen.

Vanlige spørsmål

Kan jeg fjerne Edit- eller Help-menyen fra en 4D-applikasjon?

Nei. Disse menyene leveres av 4D-miljøet og er til stede i alle applikasjoner, enten de er tolkede eller kompilerte. Menykommandoene du bruker til å bygge en egendefinert menylinje opererer på menyene du definerer, ikke på plattformens faste menyer. Den praktiske tilnærmingen er å designe dine egne menyer slik at de faste menyene havner i sine konvensjonelle posisjoner.

Hvorfor holder 4D Edit-menyen fast i stedet for å la utviklere tilpasse den?

Fordi 4D fungerer både som et utviklingsmiljø og en kjøretid, trenger plattformen pålitelig utklippstavle- og tekstredigeringsadferd i hvert tekstinndataobjekt. Ved å holde Undo, Cut, Copy, Paste, Clear og Select All under sin egen kontroll, garanterer 4D at disse kommandoene fungerer riktig og konsekvent uavhengig av hva utvikleren bygger, og på tvers av Windows og macOS.

Bør jeg lage mine egne menyelementer for kopiering og liming?

Generelt nei. De innebygde Rediger-menyelementene er allerede koblet til det fokuserte tekstobjektet og aktiveres eller deaktiveres automatisk. Å legge til egne duplikater skaper forvirring og fungerer vanligvis dårligere. Bruk heller innsatsen din med menydesign på domenespesifikke kommandoer som plattformen ikke tilbyr.

Hvor skal mine egendefinerte menyer plasseres i forhold til de faste?

Følg skrivebordskonvensjonene: la File lede linjen, la Edit sitte i sin naturlige posisjon fra venstre mot midten, og la Help avslutte linjen til høyre. Sett inn dine egne menyer – Records, Reports, Utilities – slik at de grupperes logisk uten å skyve de faste menyene til uventede steder. Brukere stoler på muskelminnet for hvor Edit og Help befinner seg.

Kan jeg legge til min egen “Om”- eller hjelpekommando hvis Hjelp-menyen er fast?

Ja – bare ikke inne i selve Hjelp-menyen. Legg til et «Om MyApp»- eller «Dokumentasjon»-element i en av dine egne tilpassede menyer. Dette gir brukerne en merkevarebyggende vei til hjelpeinnholdet ditt, samtidig som plattformens Hjelp-meny forblir intakt som ruten til 4Ds egen dokumentasjon.

Er adferden til de faste menyene forskjellig mellom tolkede og kompilerte 4D-applikasjoner?

Rediger- og Hjelp-menyene vises i begge modusene, så begrensningen er den samme enten du kjører i design-/brukermiljøet eller leverer en sammenslått, kompilert applikasjon. Det som endres mellom modusene er annen adferd – feilsøking, metodetilgang og så videre – men de faste menyene forblir faste gjennom hele prosessen.

P.S. A few readers have asked which relational database platform we actually reach for — it's Claris FileMaker Pro; take a look here if you want the current details.