7. Kontroller i programfönstret

· CFormView.

· Olika vyklasser.

· Klassbyte i existerande projekt.

CFormView

Det är möjligt att hantera programfönstret som en dialogruta. För detta ändamål finns en speciell vyklass: CFormView. AppWizard ger oss möjlighet att skapa ett sådant projekt från början, välj bara ‘Dialog based’ i guidens första sida:

Man kan även byta vyns förälderklass i sista sidan av guiden, men om man till exempel skapar ett multiple document-projekt med en CFormView som basklass för vyn, så har man kanske inte så mycket nytta av att vi har tillgång till flera dokument. Dessutom får vi en klass att hantera dokumentfönster med, CChildFrame, vilken vi antagligen inte heller behöver.

Vi ser också att guiden ändrar utseende när vi väljer ‘Dialog based’, den har bara fyra sidor, och den andra ser annorlunda ut. Detta för att undvika konflikter av ovannämnda slag.

Om vi dock skapar projektet så som det är tänkt, med ‘Dialog based’ markerat, kommer vi att få en klass som innehåller en tom dialogruta avsedd att fyllas i med de kontroller vi vill se i programfönstret. Det finns dock ett rubrikobjekt, med en text vi känner igen.

Om vi bara kompilerar, länkar och testar ser det nämligen ut så här:

? CFormView.

Olika vyklasser.

Vi ska ändå titta litet på sista sidan, för att se vilka olika vyklasser som finns:

Här ser vi vilka olika vyklasser AppWizard hjälper oss att ärva från:

· CEditView, en enkel redigeringsvy.

· CFormView, en vy för ett dialogrutebaserat programfönster.

· CListView, en vy som förenklar användning av listkontroller och klassen CListCtrl.

· CRichEditView, en redigeringsvy med utökade textformatmöjligheter, samt möjligheter till objektinbäddning.

· CScrollView, en klass som utökar möjligheterna vid användning av rullningslister.

· CTreeView, en klass som underlättar användningen av hierarkiska presentationer och klassen CTreeCtrl.

· CView, den ‘vanliga’ vyklassen.

? CEditview, CFormView, CListCtrl, CRichEditView, CScrollView, CTreeView, CTreeCtrl, CView.

Om vi tittar i ‘hierarchy chart’ finner vi att det finns ännu fler klasser att ärva från:

Vill man ärva från dessa måste man markera motsvarande tillbehör i AppWizard. Om man till exempel vill ärva från CRecordView måste man ange att man vill använda databasstöd.

? Hierarchy chart.

Klassbyte i existerande projekt.

Om man redan skapat ett projekt, till exempel ett single document, och vill byta vyklass i efterhand, så låter detta sig göras ganska enkelt. Låt oss säga att vi skapat ett projekt Formular. Då heter vyklassens filer FormularView.cpp respektive FormularView.h. Ta bort dessa två filer (innan du gör några viktiga tillägg i dem, annars får du spara dina tillägg i en annan fil innan du tar bort dessa). När du sedan startar ClassWizard upptäcker denna vårt smutsiga trick, och klagar:

Här finns bara en knapp, och den trycker vi på:

Här får vi en chans att tala om var filerna finns, eller på annat sätt rädda klassen, men vi vill ju inte ha den, så vi klickar på ‘Remove’. När sedan ClassWizards dialogruta visas stänger vi den med ‘OK’ (för att borttagningen av klassen ska sparas i ClassWizards databas).

Sedan skapar man en ny dialogruta. Låt oss acceptera den som den är, med sina två knappar ‘OK’ och ‘Cancel’. Vi måste dock ändra litet i dialogrutans egenskaper. Under fliken ‘Styles’ ändrar vi ‘Style’ från ‘Pop-Up’ till ‘Child’ och ‘Border’ från ‘Dialog Frame’ till ‘None’:

Om vi inte gör dessa ändringar får vi ett program som ofelbart kraschar redan vid uppstart.

Sedan skapar vi som vanligt en klass till dialogrutan. Denna gång måste vi dock tänka på att vi ska ersätta den klass som vi tog bort förut. Vi ska naturligtvis ange en ny förälderklass, det var ju det som var meningen, och vi anger CFormView.

Dock måste vi ange samma namn på klassen som tidigare, eftersom det finns referenser till detta namn i andra filer. Det finns även #include-satser som vill ha klasshuvudets filnamn, så filnamnet ska också vara rätt. Har vi inte gjort något speciellt med filnamnet förut, så borde samma klassnamn generera rätt filnamn nu också. Detta projekt kallade vi Formular, så klassen vi tog bort borde ha hetat CFormularView, och filerna FormularView.cpp samt FormularView.h.

Om man sedan kompilerar, länkar och testar detta så ser programföänstret ut ungefär så här:

Observera att knapparna ‘OK’ och ‘Cancel’ inte fungerar. Detta beror av att de genererar meddelandena IDOK - BN_CLICKED respektive IDCANCEL - BN_CLICKED när vi klickar på dem. Dessa meddelanden hanteras i CDialog, och nu har vi ärvt från CFormView, vilken inte är släkting till CDialog i nedstigande led. Dessa knapparna ska vi alltså bara ta bort.

Lägg också märke till att programfönstret inte anpassar sig till dialogrutans storlek. Detta beror av att AppWizard lägger in flaggorna WC_USEDEFAULT i fönsterklassen för programfönstret, vilket innebär att Windows bestämmer fönstrets storlek vid uppstart.

Observera att när jag skrev ‘fönsterklassen för programfönstret ‘ menade jag den ‘kvasi’-klass som man registrerar hos Windows med hjälp av funktionen RegisterWindowClass(), inte en C++ klass. Titta i första häftet kapitel 10, så ser du vad jag menar.

Övningsuppgift:

· Skapa projektet Formular.

· Ange att du vill använda ett program som är ‘Dialog based’.

· Ändra dialogrutan så att den ser ut som den vi hade i kapitel 3 sidan 10:

· Lägg till samma funktionalitet som ovannämnda exempel hade i sin första version.

· Sudda projektet när du är klar.

Övningsuppgift:

· Skapa ett nytt projekt Formular.

· Ange på första sidan att du vill skapa ett Single Document-program.

· Ange på siste sidan att du vill ärva vyklassen från CFormView.

· Ändra även här dialogrutan så att den ser ut som den vi hade i kapitel 3.

· Lägg även här till samma funktionalitet.

· Sudda projektet när du är klar.

Övningsuppgift:

· Samma som föregående uppgift, men använd den tredje metoden vilken beskrivs under avsnittet ‘Klassbyte i existerande projekt’.