Will auch noch mein Senf dazu abgeben!
SAFE_DELETE ist, wie die Funktion hier aufgeführt wurde nich sinnvoll. Ersten ist, wie bereits gesagt, das löschen eines Nullzeigers ohne Konsequenz und zweitens bringt die Zeile:
pPointer = NULL; garnichts, da der Zeiger nach Außen hin nicht auf Null gesetzt wird.
Eine Variante die laufen würde wäre folgende:
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
8
|
template <typename T> inline void SAFE_DELETE (T *&pPointer)
{
//if (pPointer)
{
delete pPointer;
pPointer = NULL;
}
}
|
Die Funktion FAIL find ich irgendwie witzlos. Erstmal braucht man nicht die ganzen if-Anweisungen, man kann das mit einer Zeile regeln.
|
C-/C++-Quelltext
|
1
2
3
4
|
inline unsigned long FAIL (unsigned long Value)
{
return ( Value > 0 );
}
|
Außerdem frage ich mich warum du für den Rückgabewert nicht
bool verwendest. Dann reicht folgendes:
|
C-/C++-Quelltext
|
1
2
3
4
|
inline bool FAIL (unsigned long Value)
{
return Value;
}
|
Errorcodes... naja, sind halt Patrickstyle. Aber so viel Freunde für
Element sind wirlich unschön. Je mehr Elemente es gibt desto länger wird die Liste, d.h. viel Wartungsaufwand und viel zu viele Freundschaften, mit denen man sowiso vorsichtig umgehen sollte.
Ansonsten könntest du bei deinen Klassen auf die
const-correctness achten. Zum Beispiel die Methoden aus
Element:
|
C-/C++-Quelltext
|
1
2
3
4
|
inline unsigned long get_id () const {return m_ID;} // Liefert die ID
inline HWND get_handle () const {return m_Element;} // Liefert das Handle des Elements
inline HWND get_parent () const {return m_Parent;} // Liefert das Handle des Parent Fensters zurück
inline unsigned long get_type () const {return m_Type;} // Liefert den Typ des Elements
|
Desweiteren sind Methoden die in der Klassendeklaration implementiert wurden auch direkt inline. D.h. das
inline ist in diesem Fall redundant.
Element fungiert desweiteren als Basisklasse für die ganzen Controllklassen, daher sollte Element auf jedenfall einen virtuellen, evtl sogar reinvirtuellen, Destruktor haben!
Dann ist mir aufgefallen das du häufig OK aus Methoden zurückgibst obwohl sonst keine Fehler auftreten. Was hat das für einen Grund? Wenn sowiso nichts schief gehen kann reicht als Rückgabetyp ein einfaches
void vollkommen aus.
Die ganzen GUI-Control Klassen sind ansonsten ja ganz nett. Allerdings ist es witzlos GUI Element auf irgendwelche Fenster zu schmeißen ohne deren Notifikationen zu behandeln. D.h. ich vermisse hier ganz dringend eine Funktionalität auf Notifikationen zu reagieren!!! Ansonsten macht das wirklich wenig Sinn! (Der Umweg über die WinProc des Parents find ich nich ausreichend Konfortabel eigentlich, nur so als Verbesserungstip
).
Nun zur Klasse
Window. Es ist nicht wirklich toll für jedes Element eine add_XYZ Funktion zu erstellen. Erstmal wird da egtl immer das selbe abgehandelt und zweitens ist der Wartungsaufwand auch hier viel zu hoch. Du solltest stattdessen z.B. die add_ Funktionen in die einzelnen Elemente auslagern und den Parent übergeben.
Hm, zum Schluss aber noch was positives. Finde das Tutorial an sich gelungen, nur halt z.T. verbesserungswürdig! Aber trotzallem gute Arbeit!
grüße