A
Biwill schrieb:
Ich hoffe AndreasW schaut mal wieder rein.
Da bin ich wieder War auf Wochenend- Tour...
Biwill schrieb:
In deinem Builder Tutorial arbeitest du aber mit Messages.
ähm, keine Ahnung was du meinst. Gib mir doch noch ein Hinweis bezüglich des Themas und Abschnittes. Vielleicht muss ich da ja noch was verbessern, wenn das Thema vomn mir nicht klar genug oder misverständlich ausgeführt wurde
Deine Implementation des Ereignisses sieht aber richtig aus. So muss es sein..
Biwill schrieb:
Insbesondere bei dieser stell ich mir das nämlich schwierig vor, den wenn dann statt der Methode direkt erst der Aufruf der Mesage verschickt wird abeitet der doch danach weiter ab und wartet nicht, bis die Message erfolgreich verarbeitet wurde. Oder täusche ich mich da?
wo liegt der Unterschied zwischen SendMessage (Perform/Broadcast) und PostMessage ?
Alexander Sulfrian schrieb:
Ich mache das immer so wie du! Messages sind wahrscheinlich nur wichtig wenn man sie auch außerhalb der Komponente abfrage können soll, oder?
naja, vom Prinzip her schon.
Etwas weiter gedacht, macht es aber schon Sinn. Nimm mal an, jemand möchte deine Komponente als SubKomponente verwenden. Er möchte aber auch auf Ereignisse der SubKomponente reagieren. Wenn er nun aber die Ereignisse (Methodenpointer) der SubKomponente benutzt kann der Anwendungsentwickler dieses aber nicht mehr )*. Somit sich Messages, die zum Parent und zum Owner geschickt werden durchaus sinnvoll. Vielleicht hab ich diese Aspekte im Tutorial noch nicht ganz rund angesprochen...
Ist ja auch erst mal eine Grundlage, ich werd da noch dran arbeiten und ausbauen.
)* Das weiterreichen von Methodenpointern innerhalb eine Komponente zu SubComponenten erscheint nur auf den ersten Bilck sicher. Wenn Komponeten zur Laufzeit dynamisch erzeugt und wieder zerstört werden, kann es durchaus passieren, dass Methodenpointer ins "Nichts" führen und Zugriffsverletztungen verursachen.
Man sollte einfach hinnehmen, das ein Pointer halt nur eine Adresse aufnehmen kann. Jede weitere hin und her zwitscherrei kostet Sicherheit und ist nicht Vertretbar.
Simples (ähnliches) Beispiel:
erzeuge eine Kompo. die auf das Ereignis Rezize des ParentForm reagiert.
macht dabei eine zwitscherrei wie (nur Pseudocode):
im Konstruktor:
OldFormResize= GetParentForm()->OnResize;
GetParentForm()->OnResize=FromResize;
in der Methdoe FormResize sowas wie:
ShowMessage("FormResize");
if(OldFormResize)OldFormResize(GetParentForm());
im Destruktor
GetParentForm()->OnResize=OldFormResize;
soweit die Testkomponente.
nun zieh 4 dieser Komponeten in dein Formular.
Du wirst feststellen, dass es funktioniert.
nun lösche die zweite Komponente zur Laufzeit ....
Joh, und das Übel nimmt seine Lauf...