Jag har ett VB6SP6-program som jag har ett InstallationsPaket (IP) klart till. I den nuvarande versionen känner IP av vilken Windowsversion användaren har och väljer rätt folder på CD-skivan och installerar rätt version. Jag har tre varianter, en för Win95, Win98, övriga Win.

Nu har jag fått för mig att jag skulle vilja anpassa programlayout till den skärmupplösning som användaren har. Låt oss säga att jag vill ha tre varianter 800x600, 1000x... och 1200x... Om jag då valde samma upplägg som jag redan har, dvs att IP får känna av skärmupplösningen och beroende på värde och Win-vesion så aktiveras rätt programversion. Det blir då sammanlagt 3x3 dvs 9 versioner.
Det får i och för sig plats på skivan, men jag ser en del nackdelar med det sista steget. Användaren kan ju mycket väl ändra skärmupplösningen av något skäl (det gör jag själv ibland) och då är det helt plötsligt fel programversion som är installerad på användarens dator. Användaren kan skaffa en bättre skärm med en bättre skärmupplösning och då blir det likaledes fel...

Ett annat sätt vore att i programmet använda en avkänning på skärmupplösningen och beroende på värdet rita upp komponenterna med hjälp av kod (olika stora). Blir det programmet tungt och trögt? Ska denna avkänning i så fall ligga i Form_Acitvate eller Form_Load event?

Hur ska man egentligen göra? Erfarenheter, synpunkter?

<b>Denna eviga fråga</b>

Jag tycker att du skall begränsa dig till 800*600 och 1024*768 dom andra får ta det som det är.

Om du kollar mitt uppskick Segeltävlingar Programarkivet:Administrera Segeltävlingar så kan du se hur jag löst det i Form_Load och ResizeForm.

Vet inte hur det är nu med bärbara , men när jag gjorde program så var huvudregel
att det skulle bli rätt på en bärbar 800*600 .

Jag vidhåller nog att man skall utveckla i 800*600 ett tag till.
Konsekvensen blir att dom(800*600) inte kan använda ditt program om dom inte ändrar sin upplösning.

Själv använder jag 800*600 därför att det passar min syn text mm.Jag tar heller problemmet med scroll hit och dit.

Du rörde till det något SvenPon, tycker jag. Jag har programmet nu gjort så att Form1 fyller hela skärmen med (800x600). Om användaren använder 1200x blir det en liten ruta mitt på och onödigt litet. Jag vill utnyttja hela skärmen även i fallen med 100ox... och 1200x... Dessa högupplösta användare får helt enkelt se mer info än lågupplösta! Bärbara datorer har idag som standard minst 1000x och i flesta fall 1200x...
Hur som helst tolkar jag Dig som att Du lägger in avkänningen och anpassningen i Form_Load-event. Jag ska studera Ditt exempel med Rezise.
Är det överhuvudtaget möjligt att ange storlek på Form1, alla tesxtrutor, flexgridar mm (hela layouten)genom kod?

<b>Du rörde till det något SvenPon, tycker jag.</b>
Så här svarade jag
<b>Jag tycker att du skall begränsa dig till 800*600 och 1024*768 dom andra får ta det som det är. </b>
Vad är det som är oklart i denna formulering ???

Kan inte hjälpa att du har läs och språkförståelsesvårigheter.
Om du inte klarar ren <b>plain Swedish</b> så är det inte mitt fel

Utveckla i 800*600 använd mitt förslg på ResizeForm för användare som kör med högre upplösning. !
Om du samtidigt har förstånd att använda CenterScreen på Formen så får du godkänt !

Utveckla i 1200 du kallar så får du se vad du får för reaktion , d..h....

> <b>I den nuvarande versionen känner IP av vilken Windowsversion användaren har och väljer rätt folder på CD-skivan och installerar rätt version. Jag har tre varianter, en för Win95, Win98, övriga Win.</b>

Detta är generellt sätt fel. Varför har du olika programversioner för olika versioner av Windows? Det behövs inte. Titta på alla de stora vanligaste programmen, de har det inte så. I princip det enda som går som undantag är hårdvarunära saker såsom drivrutiner.

> <b>Nu har jag fått för mig att jag skulle vilja anpassa programlayout till den skärmupplösning som användaren har. </b>

Vilket inte heller är bra. Applikationer ska inte anpassas till någon upplösning alls. Helt enkelt eftersom att det finns så många upplösningar. Tex på min laptop så kör jag 1024x768, när jag sätter samma laptop i dockningsstationen till en stationär skärm så får jag 1280x1024. Denna stationära skärm har en Pivotfunktion som gör att jag vrider skärmen 90 grader och får då 1024x1280. Spelar jag tex CivIII så flippar upplösningen om till 800x600 och då Alt-Tab jag mig till de program som ligger i bakgrunden. När jag kopplar upp mig hemma så kör jag med 1600x1200. Allt med samma dator alltså. Du kan inte veta vilka upplösningar som dina klienter använder, därför ska du inte utveckla applikationera för det heller.

Nästa sak är att när man kör höga upplösningar som 1600x1200 så har man inte längre applikationerna i fullskärmsläge, utan man öppnar en applikation och sedan drar man ut den i höjd/sidbredd till den storleken som känns bekväm. Därför är aldrig upplösningen intressant utan möjligtvis applikationens aktuella fönsteryta.

Där har du två anledningar till varför du inte ska gå in på det spår du funderar på.

Nästa sak är att titta på hur andra gör. Jag startade lite applikationer här på jobbet och INGEN av dom är satta till specifika upplösningar, utan de anpassar sig till hur stort jag gör fönstret. Tex Word, Excel, Notes, Acrobat Reader, Internet Explorer, Nokias mjukvara, Dameware, osv.

Du ska utveckla i 800*600.

Oavsett vad användaren har för skärmstorlek ska du sätta formen till maximum resize när den öppnas
och i form_resize ska du anpassa alla kontrollerna för den aktuella formens storlek.

Så om användaren drar i en kant på formen så ska alla kontroller förstoras på det sätt som ser bäst ut till formens nya storlek.

Gör en metod som du anropar både från form_resize och från form_load.

Va gla jag blir Jenny :-) Det är rätt då har användren handlingsfrihet och kan använd programmet.

Om man kontrollerar så skriver Jenny och Puman djä.. bra.
Säger inte detta för att hon just ovan höll med mig, nästa gång håller hon med nån annan.

Varför är det så lite flickor med "sav" i huvudet som besöker denna "tomt" ?

Tack för många tänkvärda synpunkter. Det var väl ett feltänk från min sida (inget ovanligt förresten... ). Jag tror att jag ska ge mig in på Jennys förslag, det verkar förståndigt. Är det någon som känner till något exempel man kan titta på?

RickardD.! Du säger att det generellt sätt är fel med olika versioner av program beroende på Windows-version. Hur ska man lämpligen göra då?
För att programmet ska fungera hos användare med olika Win-versioner ska olika patchar köras under installationen, i övrigt är programversionerna identiska...

Det ska inte behövas olika versioner för olika windows versioner.
Vad är det för typ av saker du har/gör som inte fungerar i mer än en windows version?

En sak går att göra på minst 10 olika sätt och de flesta saker går att utföra på ett sätt som passar alla slags versioner eller de flesta av windows.

> <b>Hur ska man lämpligen göra då?</b>

Identifiera de krav som du som utvecklare ställer på målmiljön, ex viss version på MDAC och viss version på IE osv. Se även till att din applikation inte kräver just den versionen utan _lägst_ den versionen. Dokumentera de olika kraven för resp OS och lägg upp det tillsammans med ditt program, som websida eller som readme. Det är den första biten.

Nästa bit är att tillsammans med din mjukvara, antingen som seperata nerladdningar, eller tillsammans på en CD, distribuera respektive uppdateringar för respektive OS. Alltså inte i din setupfil utan som egna installationer.

Sedan kan du i ditt installationsprogram göra en koll för att se om de hotfixarna/versionerna som din mjukvara kräver finns installerade eller inte. Och antingen att du ger användaren möjlighet att installera frånwebb/CD inuti din setup eller att du skriver någon form av loggfil.

Jag har varit med om mjukvaror som per automatik installerar hotfixar åt en. Det är helt förödande. Ex så hade vi på mitt förr-förr-förra arbete en intern utvecklingsavdelning som gjorde en tidredovisningsapplikation i någon gammal version av VB. Under installationen så tvingade den på MDAC som var en äldre version än den som följde med Win2000 vilket naturligtvis resulterade i att jag fick installera om min maskin.

Jag har varit i liknande situationer på mitt förra jobb. Då kom utvecklarna med en applikation som installerade Oracles databasdrivrutinspaket utan att fråga. Och detta paketet var naturligtvis inte samma version som var interncertifierat på företaget för alla andra applikationer. Resultatet blev att mjukvaran inte köptes in utan vi valde en konkurrerande mjukvara som betedde sig som den skulle.

Ställ krav på målmiljön, men påtvinga aldrig uppdateringar.

Jenny! För Win95-användare låter jag IP köra Dc95inst.exe och för Win98-användare låter jag köra dcom98.exe, efter installationen av huvudprogrammet. För övriga Win är det inga extra filer/patchar att köra. Jag har svårt att se hur jag ska kunna undvika tre olika foldrar på min skiva... Ser Du någon möjlighet?

RichardD! I princip tycker jag att Du (och även Jenny) har rätt i ert tänkande, men det känns som att det är over do. Mitt kunskapsdjup är inte tillräckligt för att klara en så systematisk utvecklingsprocess. Om den sämsta/lägsta målmiljön ska sätta standarden, hamnar jag i direkta svårigheter. Jag har ingen aning om vad Win95 klarar i termer av ADO, Accessanslutningar, Flexgrid:ar mm (utan patch). Jag misstänker att det helt enkelt inte är möjligt. Att brottas med detta i "oändlighet" och få sämre funktionalitet, förefaller vara ett sämre alternativ än att skicka med en patch (Dcom98.exe eller Dc95inst.exe). Även om det inte är en ideal lösning, förefaller den vara lagom enkel och praktisk...

RichardD! Ang skärmupplösningar. Kom att tänka så här (Jag har ännu inte fördjupat mig i Jennys förslag om 800x600 plus Resize). Om jag lägger in en avkänning i Form_load event på skärmupplösning och beroende på värde låter rita upp en Form med rätt strolek på knappar och rutor mm, betyder det att om användaren byter skärmupplösning och startar programmet så väljs "rätt" Form med lämplig storlek. Enda haken skulle vara om användaren vill byta skärmupplösning med mitt program igång, då kan det bli problem. Dessa försvinner dock nästa gång användaren startar programmet. Vad är det för fel på den tankegången?

Du ska absolut utveckla i 800x600 med Resize. Framförallt för att slippa om användaren ändrar skärmupplösning.

Dessutom måste du ändå göra en resize metod om användaren beslutar sig för att ändra storlek på sitt fönster. Användaren kan dra i formens kanter och kan klicka på minimize och maximize knapparna uppe i formens kant.

Antingen sätter du formen att maximeras när den ska visas (görs i designläge på en av prepertynarna)
eller innan du anropar denna formen så skriver du
<code>
frm.width = screen.width
frm.height = screen.height
frm.top = 0
frm.left = 0
</code>
screen anger bildskärmens egenskaper. Sätt propertyn maximize om du vill utnyttja hela skärmen. Beräkna formens storlek om du bara vill utnyttja en del av skärmens storlek där du då drar av lite width och height och anger en annan top och left.

I din resize metod så räknar du exempelvis ut en knapps position ex nere i högra härnet med ett mellanrum till formens kanter:
<code>
button.left = me.width - button.width - 100
button.top = me.height - button.height - 100
</code>

textbox storlek:
<code>
textbox.Width = me.width - 300
textbox.Height = me.height - 300
</code>

osv....

---------------------------------------------------------------------

ok om det bara gällde dcom så räcker det med två olika installationskit och inget annat.

Tack Jenny, nu ska jag gripa mig an hantverket

Jenny, jag måste anmärka på din kod.

Movemetoden är effektiv att använda för att positionera kontroller och formulär.
Använd edast Left, Top, Width och Right om du ENDAST skall förändra en av dessa egenskaper.

När man positionerar kontroller innuti ett formulär använder man ALDRIG Form.Height eller Form.Width. Detta är för att dessa är formulärets yttre mått. Kanterna på fönster kan skiljer mellan t. ex. Win 2000 och Win XP. Vilket innebär att du kontroller kommer bli fel placerade.

Använd istället Form.ScaleLeft, Form.ScaleTop, Form.ScaleWidth och Form.ScaleHeight.

Om du inte förändrat Form.ScaleLeft och/eller Form.ScaleTop kan ni bortse ffrån dessa då de är 0.

Här är ett exempel som positionerar fyra knappar i varje hörn av ett formulär:
<code>
Private Sub Form_ReSize()
On Error GoTo Form_ReSize_Err
cmdTopLeft.Move Me.ScaleLeft, _
Me.ScaleTop

cmdTopRight.Move Me.ScaleLeft + Me.ScaleWidth - cmdTopRight.Width, _
Me.ScaleTop

cmdBottomLeft.Move Me.ScaleLeft, _
Me.ScaleTop + Me.ScaleHeight - cmdBottomLeft.Height

cmdBottomRight.Move Me.ScaleLeft + Me.ScaleWidth - cmdTopRight.Width, _
Me.ScaleTop + Me.ScaleHeight - cmdBottomRight.Height

Form_ReSize_Exit:
Exit Sub

Form_ReSize_Err:
Select Case Err.Number
Case Else
Debug.Print Err.Number, Err.Source, Err.Description
Resume Next
End Select
End Sub
</code>

Om du har ett formulär med en toolbar, en listview och en status bar. Det flesta program ger användsaren möjlighet att dölja Toolbar och statusbar.

Resize koden kan då se ut så härt:
<code>
Private Sub Form_ReSize()
On Error GoTo Form_ReSize_Err
Listview1.Move Me.ScaleLeft, _
Me.ScaleTop + (ToolBar1.Height And ToolBar1.Visible), _
Me.ScaleWidth, _
Me.ScaleHeight - (ToolBar1.Height And ToolBar1.Visible) - (StatusBar1.Height And StatusBar1.Visible)
Form_ReSize_Exit:
Exit Sub

Form_ReSize_Err:
Select Case Err.Number
Case Else
Debug.Print Err.Number, Err.Source, Err.Description
Resume Next
End Select
End Sub

Private Sub mnuShowToolBar_Click()
ToolBar1.Visible = Not ToolBar1.Visible
mnuShowToolBar.Checked = ToolBar1.Visible
Form_ReSize
End Sub

Private Sub mnuShowStatusBar_Click()
StatusBar1.Visible = Not StatusBar1.Visible
mnuShowStatusBar.Checked = StatusBar1.Visible
Form_ReSize
End Sub
</code>

Ah, scale ja just det. Jag kom inte på vad det hette så jag utgick från height och width istället. Har ingen vb tillgänglig på denna datorn... :-)

Alldeles rätt att movemetoden är bättre!

Jenny M och Andreas H! Jag har nu ordnat till min form så att positioner och storlek för vissa komponenter ändras när användaren ändrar storleken på formen. Jag måste säga att jag tycker Resizemetoden verkligen är ett elegant sätt att lösa problematiken med olika skärmupplösningar. Mycket bättre än den lösning jag från början var inne på, med avkänning av aktuell skärmupplösning mm.
Jag tror vidare att det är många med mig som har funderat på problemet någon gång, men inte funnit någon hanterlig lösning. Om Du Jenny eller Du Andreas (eller varför inte tillsammans) skrev om denna lösning och lade in på Tips/Tricks skulle många vara glada.
Hur som helst. Jag tackar och bugar för Ert engagemang och Er generositet. Nu har jag blivit en något litet bättre programmerare!