Dialoge händisch oder mit Ressource schreiben?

aVoX

Hallo!
Ich mache gerade meinee ersten Gehversuche in MFC. In irgendeinem Forenpost auf dem MSDN habe ich gelesen, dass Dialoge üblicherweise mit einer Ressourcendatei geschrieben werden.
Ich persönlich kann dem Vrgehen nichts abgewinnen, da das ganze ziemlich unübersichtlich wird und man nur schwierig Controls ändern kann.
Zum Beispiel:

// RC-Dialog mit ProgressBar
CMyDlg( CWnd *pParent ) : CDialogEx( CMyDlg::IDD, pParent )
{
}

// Annahme: Im Dialog soll die Fortschrittsanzeige auf 80 gesetzt werden,das Maximum auf 120, das Minimum auf 0 und die Hintergrundfarbe auf RGB(128,128,0)
BOOL CPrefsDlg::OnInitDialog()
{
    if ( !CDialogEx::OnInitDialog() )
        return FALSE;

    // ziemlich sinnfrei, da ich hier das ProgressCtrl erst recht instanziere
    CProgressCtrl *pProgress = (CProgressCtrl *) GetDlgItem(IDC_PROGRESS);
    pProgress->SetBkColor( RGB(128, 128, 0) );
    pProgress->SetPos( 80 );
    pProgress->SetRange( 0, 120 );
    return TRUE;
}

Macht ihr eure Dialoge per Hand, oder bastelt ihr euch die im RC-Editor zusammen und warum?

Danke im Voraus, aVoX.

Mechanics

aVoX schrieb:

Ich mache gerade meinee ersten Gehversuche in MFC.

Der beste Tipp den ich dir geben kann ist, wenns geht, lass das bleiben. Noch nie sowas hässliches wie MFC gesehen.

CTecS

CProgressCtrl *pProgress = (CProgressCtrl *) GetDlgItem(IDC_PROGRESS);

also das was du machst dir nen Zeiger auf eine Dialogresource zu organiesieren, das hat nun mal gar nix mit selbst erstellen zu tun, an sonstens würdest du dein Progress doch mit Create(...) erstellen oder hast du nur das stück source nicht mit gepostet.

Also wenn dann mach ich die Dialoge mit dem Resourceneditor, warum sollte ich mir die arbeit machen wie positionen aus zu loten, vielleicht x mal das Programm zu starten um dann festzustellen das es immer noch nicht passt.

Wobei kommt immer drauf an was man macht also was das Ergebnis sein soll

aVoX

CTecS schrieb:

also das was du machst dir nen Zeiger auf eine Dialogresource zu organiesieren, das hat nun mal gar nix mit selbst erstellen zu tun, an sonstens würdest du dein Progress doch mit Create(...) erstellen oder hast du nur das stück source nicht mit gepostet.

Ja schon, aber wenn ich mir den Dialog selber zusammenbaue, kann ich einfach auf die Membervariablen zugreifen, würde ich es im RC-Editor machen, müsste ich mir zuerst für jedes Control, das ich anpassen oder verändern will einen Zeiger beschaffen.

Mechanics schrieb:

Noch nie sowas hässliches wie MFC gesehen.

Aber im Gegensatz zu Win32 immerhin objektorientiert...

CTecS

aVoX schrieb:

Ja schon, aber wenn ich mir den Dialog selber zusammenbaue, kann ich einfach auf die Membervariablen zugreifen, würde ich es im RC-Editor machen, müsste ich mir zuerst für jedes Control, das ich anpassen oder verändern will einen Zeiger beschaffen.

Wieso musst du dir nen zeiger besorgen, du kannst auf jede Resource eine Menbervariable legen welches das object is, also hast du da von haus aus den Zeiger, seh ich nicht als Problem.

Solche aktionen wie GetDlgItem(...) mach ich nur wenn ich an einer Stelle mal nen Zeiger auf eine Resource brauche, an sonsten macht es mehr Sinn da Gleich eine Variable drauf zu legen. Denn eigentlicher weise ist dein Code Bugy weil du den Zeiger den du erhälst nicht mal auf Gültigkeit prüfst, genau so könntest du NULL zurück bekommen.

@Mechanics
Sinnfreie Kommentare abgeben macht nun wirklich keinen Sinn, denn wo ist denn deine Alternative?

Bitte jetzt keinen Kommentar das MFC tot ist und von MS nicht mehr unterstützt wird, das entspricht ja nun gar nicht der Wahrheit, auch wenn sich MS jetzt mehr auf andere Sachen stützt und C# und der ganze .NET kram jetzt ganz angesagt ist und jeder 2 Sagt lern C# weil das besser ist.

AndyDD

CTecS schrieb:

@Mechanics
Sinnfreie Kommentare abgeben macht nun wirklich keinen Sinn, denn wo ist denn deine Alternative?

Bitte jetzt keinen Kommentar das MFC tot ist und von MS nicht mehr unterstützt wird, das entspricht ja nun gar nicht der Wahrheit, auch wenn sich MS jetzt mehr auf andere Sachen stützt und C# und der ganze .NET kram jetzt ganz angesagt ist und jeder 2 Sagt lern C# weil das besser ist.

Da klinke ich mich auch gerne noch mal in die Diskussion mit ein. Ich gebe CTecS da voll Recht. Die Verwendung von Ressourcen nimmt ne Menge Arbeit ab und das ist ja auch das, was das ganz "Visual" macht. Ebenfalls schon angesprochen kann man sowohl Controlvariablen als auch Wertevariablen für jedes Control vergeben.
Was vielleicht etwas mehr Arbeit macht ist, wenn man den Standardcontrols ggf. andere Schriftarten zuweisen will oder deren Farben ändert. Aber wenn man weiß wie es geht und es auch verstanden hat, dann ist das auch kein Problem.

aVoX

AndyDD schrieb:

Ebenfalls schon angesprochen kann man sowohl Controlvariablen als auch Wertevariablen für jedes Control vergeben.

CTecS schrieb:

du kannst auf jede Resource eine Menbervariable legen welches das object is,

Auwei, das hab ich nicht gewusst/die ganze Zeit gesucht
Danke für eure Antworten!

Mechanics

CTecS schrieb:

@Mechanics
Sinnfreie Kommentare abgeben macht nun wirklich keinen Sinn, denn wo ist denn deine Alternative?

Ich finde den Kommentar nicht sinnlos. Wenn du anderer Meinung bist, ist es dein gutes Recht.
Alternativen gibts genug. Ja, z.B. .NET. Man kann die GUI in .NET schreiben und den Kern in C++, wenn man unbedingt mag. Oder man nimmt Qt, GTK oder wxWidgets. Alles wesentlich durchdachter und angenehmer, als MFC. MFC ist nicht ganz tot, hab ich ja nicht behauptet. Aber neue Projekte würde ich nie im Leben damit anfangen. Nur meine Meinung, und ich finde, das ist auf jeden Fall eine Überlegung wert, wenn man schon mit sowas anfängt. Bleibt aber jedem selber überlassen, was er dann im Endeffekt macht.

CTecS

@Mechanics:

ich hab nicht geschrieben das dein Kommentar Sinnlos ist sondern Sinnfrei, weil du in deinem letzten Post entgegen dem ersten auch Alternativen aufgezeigt hast. Somit ist zumindest dein letzter Post der bei dem man sieht das du net nur schreibst das MFC mist ist.

Wobei C++ und .NET in einem zusammenhang zu bringen endet meist in CLI mit .NET was ja nun schon gar nicht der Stein des weissen ist. Dann doch gleich C# nehmen.

Mechanics

CTecS schrieb:

Wobei C++ und .NET in einem zusammenhang zu bringen endet meist in CLI mit .NET was ja nun schon gar nicht der Stein des weissen ist. Dann doch gleich C# nehmen.

C++/CLI mag ich auch nicht Aber es ist zumindest eine passable Möglichkeit, kommt natürlich auf den Anwendungsfall an. Wenn die drunterliegende C++ API sehr breit ist, viele Objekte bereitstellt usw., wird es nicht einfach, da eine GUI mit .NET zu bauen. Aber wenn man die C++ Funktionalität gut kapseln und über eine kleine API ansprechen kann, wärs durchaus eine Möglichkeit, die GUI in C# zu schreiben, und die restliche Anwendung in C++. Das habe ich in einer Firma auch schon mal geschafft. Die C++ Anwendung (leider war das tatsächlich MFC) an sich war relativ umfangreich, aber wir konnten sie dann so umbauen, dass sie die "Aufträge" als XML reinbekommen hat. Damit war die Schnittstelle nach außen sehr überschaubar. Die GUI war aber auch nicht trivial, weil man viele Sachen einstellen konnte und dafür auch benutzerdefinierte Komponenten von Vorteil waren. Die GUI in C# zu programmieren war dann wesentlich angenehmer, als in MFC. Das war aber eher ein Sonderfall, geb ich zu.