dialoge wann ableiten?
-
wenn ich z.b. einen dialog habe, der aus verschiedenen controlelementen besteht und ich jetzt einen weiteren benötige, der fast gleich aussieht, aber für etwas anderes da ist. macht es sinn dann anhand diesen dialog abzuleiten? wie heissen dann die id felder ect?
z.b.
IDC_MEIN_BUTTON heisst der dann automatisch IDC_MEIN_BUTTON2?
dann müsst ich doch eigentlich nur alle funktionen neu implementieren und das wars?
-
Das Ableiten hat nichts mit den Resource-IDs zu tun... die heissen dann genau gleich...
-
Jup... du solltest dir mal das Vererben von Klassen in C++ oder besser die Grundlagen von C++ mal angucken
Ne... also... wenn der Dialog fast gleich aussieht, kannst du entweder den selben Dialog nochmal verwenden... dann aber Codeintern mal die Änderungen machen... vllt Buttontitel ändern usw... das ist ohne weiteres möglich... wenn es das ist was du willst..
-
Also das sollte man nicht tun. Vererbung hat nichts damit zutun, sich Code-Arbeit zu sparen. Das kann in die Hose gehen nach einer Zeit, weil wenn man in der Super-Klasse was ändert, gibts in der Sub-Klasse auch Änderungen, ohne das es fachlich einen Sinn macht.
Wenn B von A erbt, heißt es "B _ist_ ein A". Also, "WohnmobilDialog ist ein AutoDialog".
Aber würdest du das hier machen? "FlugzeugDialog ist ein AutoDialog"
Nur weil vielleicht der AutoDialog auch ein Eingabefeld für Gewicht (kg) hat? Nein!Das sind aber alles Basics in Objekt Orientierung.
-
Nun, aber wenn man grundlegende Elemente in zwei Klassen benötigt, die sich erst ab einem bestimmten Punkt unterscheiden, dann ist das schon sinnvoll.
Wenn ich z.b. zwei Dialoge benötige, die sich mit Mitarbeitern beschäftigen, einer für einen Büromitarbeiter und einer für einen Lagermitarbeiter, dann können durchaus viele Funktionen/Felder/Elemente ähnlich sein. Dann macht man eben einen dialog Mitarbeiter, und zwei Dialoge für die Arbeiter, die vom Hauptdialog erben. Dinge wie Geburtstag, Personal-Nr, Adresse usw. können übernommen werden, Einsatzgebietsspezifische Dinge, die nur in einem Dialog auftauchen, nimmt man in die erbenden Klassen rein.
Das spart Code-Arbeit, und ist ja auch u.A. dazu gedacht - bei Änderungen an der Personal-Nr-Formatierung beispielsweise musst Du jetzt nur eine Klasse ändern statt zwei. Das muss man eben abwägen!
-
Na wie man an die Sache heran geht, hängt doch von den Unterschieden in den Dialogen ab.
Ich nehme mal:
a) zwei Dialoge, die von einem gemeinsamen Basisdialog abgeleitet sind (der wiederum z.B. von CDialog ). Alle gemeinsamen Variablen, Eigenschaften sind dann im Basisdialog.oder
b)einen Dialog und einzelne Elemente werden kontextabhängig ein bzw. ausgeblendetTester2