Tips för Delphi-applikationer med flera upplösningar

När du utformar formulär i Delphi är det ofta användbart att skriva koden så att din ansökan (formulär och alla objekt) i stort sett ser densamma ut oavsett vad skärmupplösningen är.

Det första du vill komma ihåg tidigt i formdesignstadiet är om du kommer att tillåta att formen skalas eller inte. Fördelen med att inte skala är att ingenting förändras vid körning. Nackdelen med att inte skala är den ingenting förändras vid körning (ditt formulär kan vara alldeles för litet eller för stort för att läsa på vissa system om det inte är skalat).

Om du inte ska skala formuläret ställer du in Skalad till falskt. I annat fall ställer du in egenskapen till Sann. Ställ också in Auto-scrolla till falskt: det motsatta skulle betyda att man inte ändrar formens ramstorlek vid körning, vilket inte ser bra ut när formulärets innehåll do ändra storlek.

Viktiga överväganden

Ställ in formens typsnitt på ett skalbart TrueType-teckensnitt, som Arial. Endast Arial ger dig ett teckensnitt inom en pixel med önskad höjd. Om teckensnittet som används i ett program inte är installerat på måldatorn väljer Windows ett alternativt teckensnitt inom samma teckensnittsfamilj som ska användas istället.

Ställ in formulärets Placera egendom till något annat än poDesigned, vilket lämnar formuläret där du lämnade det vid designtid. Detta hamnar vanligtvis långt bort till vänster på en 1280x1024 skärm - och helt utanför 640x480-skärmen.

Massa inte in kontroller på formuläret, åtminstone fyra pixlar mellan kontrollerna så att en pixeländring i gränslägen (på grund av skalning) inte visas som överlappande kontroller.

För enstaka radetiketter alLeft eller OK inriktad, inställd autosize till True. I annat fall ställer du in autosize till falskt.

Se till att det finns tillräckligt med tomt utrymme i en etikettkomponent för att möjliggöra ändringar av teckensnittsbredd - ett tomt utrymme som är 25% av längden på den aktuella strängens visningslängd är lite för mycket men säkert. Du behöver minst 30% expansionsutrymme för strängetiketter om du planerar att översätta din app till andra språk. Om autosize är falskt, se till att du faktiskt ställer in etikettbredden på rätt sätt. Om autosize är sant, se till att det finns tillräckligt med utrymme för att etiketten ska växa på egen hand.

I etiketter med flera linjer, ordförpackade, lämnar du åtminstone en rad tomt utrymme längst ner. Du behöver detta för att få överflödet när texten lindas annorlunda när teckensnittets bredd förändras med skalning. Antag inte att eftersom du använder stora teckensnitt så behöver du inte tillåta textöverskridande - någon annans stora teckensnitt kan vara större än ditt!

Var försiktig med att öppna ett projekt i IDE med olika upplösningar. Formen är PixelsPerInch egenskapen kommer att ändras så snart formen öppnas och kommer att sparas i DFM om du sparar projektet. Det är bäst att testa appen genom att köra den fristående och redigera formuläret med bara en upplösning. Redigering med olika upplösningar och typsnittsstorlekar bjuder in komponentdrift och storlek på problem. Se till att du ställer in din PixelsPerInch för alla dina formulär till 120. Det är standard till 96, vilket orsakar skalningsproblem i lägre upplösning.

Om vi ​​talar om komponentdrift, ska du inte räkna om en form flera gånger, vid designtid eller körtid. Varje omskalning introducerar avrundningsfel som ackumuleras mycket snabbt eftersom koordinaterna är strikt integrerade. Då fraktionerade mängder trunkeras från kontrollens ursprung och storlekar med varje på varandra följande skalning, verkar kontrollerna krypa nordväst och bli mindre. Om du vill tillåta dina användare att omformera formuläret ett antal gånger börjar du med en nyladdad / skapad form före varje skalning så att skalfel inte ackumuleras.

I allmänhet är det inte nödvändigt att utforma formulär med någon specifik upplösning, men det är avgörande att du granskar deras utseende på 640x480 med stora och små teckensnitt och i en högupplösning med små och stora teckensnitt innan du släpper appen. Det här bör vara en del av din vanliga systemkompatibilitetstestlista.

Var noga med alla komponenter som i huvudsak är enliniga TMemos-saker som TDBLookupCombo. Redigeringsstyrningskontrollen i Windows visar alltid bara hela textrader - om kontrollen är för kort för dess teckensnitt, a TMemo visar ingenting alls (a tRedigera visar klippt text). För sådana komponenter är det bättre att göra dem några pixlar för stora än att vara en pixel för liten och inte visa någon text alls.

Tänk på att all skalning är proportionell mot skillnaden i teckensnitthöjd mellan körtid och designtid, inte pixelupplösningen eller skärmstorleken. Kom också ihåg att ursprunget till dina kontroller kommer att ändras när formen skalas - du kan inte så bra göra komponenter större utan att också flytta över dem.

Förankringar, inriktning och begränsningar: VCL från tredje part

När du väl vet vilka problem du ska tänka på när du skalar Delphi-formulär i olika skärmupplösningar är du redo för lite kodning.

När vi arbetar med Delphi version 4 eller senare, är flera egenskaper utformade för att hjälpa oss att behålla utseendet och utformningen av kontrollerna på ett formulär.

Använda sig av Justera för att justera en kontroll till den övre, nedre vänstra eller höger delen av en form eller panel och att den ska vara kvar även om storleken på formen, panelen eller komponenten som innehåller kontrollen ändras. När storleken på storleken ändras, ändras även en justerad kontroll så att den fortsätter att sträcka sig över den övre, nedre, vänstra eller högra kanten på överordnade.

Använda sig av begränsningar för att ange minsta och maximala bredd och höjd på kontrollen. När begränsningar innehåller maximala eller lägsta värden kan inte storleken ändras i storlek för att bryta mot dessa begränsningar.

Använda sig av ankare för att säkerställa att en kontroll behåller sin nuvarande position i förhållande till en förkant av sin överordnade, även om överordnade har ändrats. När dess överordnade storlek ändras, håller kontrollen sin position relativt de kanter som den är förankrad till. Om en kontroll är förankrad på motstående kanter på sin överordnade sträcker sig kontrollen när dess överordnade ändras.

procedur ScaleForm
(F: TForm; ScreenWidth, ScreenHeight: LongInt);
Börja
F.Scaled: = Sant;
F.AutoScroll: = Falsk;
F.Position: = poScreenCenter;
F.Font.Name: = 'Arial';
om (Screen.Width ScreenWidth) börjar
F. Höjd: =
LongInt (F.Height) * LongInt (Screen.Height)
div ScreenHeight;
F. Bredd: =
LongInt (F.Width) * LongInt (Screen.Width)
div ScreenWidth;
F.ScaleBy (Screen.Width, ScreenWidth);
slutet;
slutet;