"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:41545a18$0$200$edfadb0f@dread11.news.tele.dk...
[8<8<8<]
> wxWidgets har to store fordele frem for VCL og BCB:
> 1: Det er opens souce
> 2: Det kører med mange kompilere på mange platforme.
Alt andet lige er det 2 gode egenskaber - men alt andet er ikke lige.
[8<8<8<]
> Man kan naturligvis altid diskutere hvad der er pænt designet, man
> har måske en tendens til at synes at det man har brugt meget er pænt.
I det store hele syntes jeg at VCL er pænt designet, og nemt at gå til.
Det er ikke perfekt - få ting er.
> Jeg synes ikke at VCL er logisk, det tog mig f.ex. nogen tid at regne
> ud at man satte fonten til fed på en control med:
>
> Whatever->Font->Style = TFontStyles() << fsBold;
Ja, det er hverken specielt pænt eller intuitivt. Man skal nok kende Delphi
baggrunden for at værdsætte det
Ofte sætter man det op grafisk via Object Inspector'en - og så er det
ligemeget.
Hvis man skal sætte det op programmatisk, så kan man gøre det når man een
gang har set hvordan.
Ved at stille sig på propertien "Font" og trykke F1 er der ikke langt til et
eksempel der viser præcis hvordan det gøres.
For lige at sætte tingene i relation til det oprindelige spørgsmål, har du
så overvejet hvordan man gør det tilsvarende i MFC (eller Win32 API'et) ?
Jeg slog det op på side 339 i den MFC bog jeg henviste til.
Her er det væsentligste af det
if((HFONT) m_fontSample != NULL)
m_fontSample.DeleteObject();
//...
m_fontSample.CreateFont( en _masse_ parametre );
m_wndSampleText.SetFond(&m_fontSample);
og husk så lige at kalde "m_fontSample.DeleteObject()" når vinduet
nedlægges.
Hvad hvis kaldet til CreateFont fejler, når den gamle font allerede er
nedlagt ?
Udover at være komplekts er det en usikker kode stil.
Det er vist ikke helt urimeligt når jeg sagde at VCL er langt nemmere at gå
til end MFC.
[8<8<8<]
> Min hovedindvending mod BCB og VCL er stadig at det
> kun understøttes af Borland og at Borland måske
> ikke vil fortsætte af det spor.
Man afhænger af sine afhængigheder, og man slipper ikke for afhængigheder.
Man skal opveje fordele og ulemper, og gøre op med sig selv og projektet om
man kan tillade risikoen.
> Så jeg mener ikke
> at man bør starte på at bruge VCL i dag til (store)
> nye projecter,
Jeg er for så vidt enig med dig - det er dog ikke en design mæssig årsag,
men en strategisk overvejelse der ligger til grund.
Som jeg sagde i mit oprindelige indlæg er VCL et lettere tilgængeligt
alternativ til MFC hvis man skal lave Win32 applikationer.
Med hensyn til fremtidssikring, så er man i værste fald lige dårligt stillet
med MFC og VCL - i bedste fald er man bedre stillet med VCL.
Uanset valg af bibliotek, vil det til store projekter af mange grunde være
fornuftigt at gøre så meget af applikationen som muligt uafhængig af GUI
biblioteket. Det betyder f.eks. at man bør undgå at benytte klasser som
CString (i MFC) eller AnsiString (i VCL) men istedet benytte "std::string",
selvom det giver noget irriterende typekonvertering rundt omkring.
Se eventuelt bogen
Large Scale C++ Software Design
John Lakos
ISBN 0-201-63362-0
for nyttigte råd i forbindelse med design af store projekter.
Hvis det er et lille projekt, spiller afhængigheder en mindre rolle, og man
skal egentlig bare koncentrere sig om at se at få løst opgaven, og smide det
hele væk hvis man ikke kan leve med afhængighederne.
> eller hvis man skal lære at programmere.
Det man lærer ved at anvende VCL er i høj grad nyttigt hvis man vil anvende
WinForm og andre dele af .NET.
Det grundliggende problem er at det ideele GUI bibliotek til C++ ikke
findes.
Venlig hilsen
Mogens Hansen