Externe Klasse nutzt Form1

[NoMaki]

Hi.

Ich habe eine externe Klasse wo ich Komponenten aus TForm1 nutzen möchte.
Steht unter der TForm1 Klasse.

class Display : public Win32Thread
{
private:
	void run();
public:
	Display() : Win32Thread() {}
	~Display() {}
};

Wie muss ich das denn umschreiben, damit man es kann?
Ich möchte Ausgaben in das Form1->Memo1 ausgeben können.

Danke.

[Christian211]

Die Unit wo TForm1 drin includieren und dann

Form1->.. schreiben

Handelt es sich um eine Threadklasse sind allerdings Besonderheiten zu beachten (Synchonize).

[junix]

Christian211 schrieb:

Die Unit wo TForm1 drin includieren und dann

Form1->.. schreiben

Das ist - nach Gedanken der OOP das schlechteste was man machen kann! Damit ist die KLasse nämlich 0 wiederverwendbar.

Besser: Den Zeigera auf das Memo dem Konstruktor übergeben

Noch besser: Form1 holt sich die Daten über einen Timer selbst ab.

Ultimativ: Form1 holt sich die Daten selbst ab, nachdem es über eine Windows Message über eine Änderung informiert wurde.

[Christian211]

Das ist - nach Gedanken der OOP das schlechteste was man machen kann! Damit ist die KLasse nämlich 0 wiederverwendbar.

Genau das Konzept, welches die VCL vorsieht. Es geht hier nicht darum, die Klasse wiederzuverwenden, sondern die Daten der Klasse in anderen Klassen zu verwenden. Also Daten der Klasse Form1 in Form2 zu verwenden

[junix]

Christian211 schrieb:

Das ist - nach Gedanken der OOP das schlechteste was man machen kann! Damit ist die KLasse nämlich 0 wiederverwendbar.

Genau das Konzept, welches die VCL vorsieht.

Nö. Das Konzept sieht die VCL absolut nicht vor. Das ist nur das Konzept welches man als "konzeptlosen Würg mangels besseren Wissens bzw. mangels Applikationsdesign" bezeichnen kann.

Es geht hier nicht darum, die Klasse wiederzuverwenden, [...] Also Daten der Klasse Form1 in Form2 zu verwenden

Abgesehen davon, dass das vom Applikationsdesign abhängt: Es gibt wohl nen Grund wieso man klassen macht. hier siehts schwer nach der Kapselung von Funktionalität aus. Man sollte GUI und Funktionalität immer mit möglichst schmalen Schnittstellen verbinden um zum Beispiel ein Sterben einer VCL mit beschränktem Schaden zu überstehen. Oder auch, um das GUI-Konzept ändern zu können, ohne ne Penalty in der Funktionalität zu kriegen.

[Christian211]

Kann das immer noch nicht nachvollziehen:

Es geht nicht darum eine Klasse wiederzuverwenden, sondern auf Daten einer anderen schon instanzierten Klasse zuzugreifen. Keine Wiederverwendung einer Klasse.

Üblicherweise holt man sich die Struktur der Klasse (die Header) und greift auf die public Funktionen zu. Nichts anderes geschieht hier. Die Methode geben mir dann die gewünschten Daten. Hier innerhalb eines Programmes von einer Klasse zur anderen mittels Timer oder gar Messages zu arbeiten - Sorry das wäre in meinen Augen übertrieben.

Oder habe ich die Frage falsch verstanden und es ist eine Kommunikation zwischen Programmen gefragt?

[Maffe001]

@Christian211:

Schon mal drüber nach gedacht, dass du Sachen, die einmal geschrieben hast, vielleicht in ähnlicher Form bei anderen Projekten später wieder verwenden möchstet, ohne übermässig viel zu ändern oder vielleicht "neu" zu "entwickeln"?

Was ist an Messages übertrieben, wenn sich TForm nur dann aktualisiert, wenn auch wirklich Änderungen eingetreten sind? Noch besser geht es doch gar nicht, es sei denn Effizienz ist nicht wichtig.

[junix]

Christian211 schrieb:

Es geht nicht darum eine Klasse wiederzuverwenden, sondern auf Daten einer anderen schon instanzierten Klasse zuzugreifen. Keine Wiederverwendung einer Klasse.

Du darfst nicht nur den Datenfluss sondern auch die Funktionalität betrachten!

Es geht um Abläufe... Klassen sollten immer spezialisten für bestimmte Abläufe sein. Diese Abläufe kann man ggf. weiterverwenden.

Nehmen wir ein losgelöstes Beispiel: Ich hab eine Klasse die ist darauf spezialisiert, mit dem COM-Port umzugehen. Das kann sie gut, und das macht sie gerne. Wenn sie jetzt aber die Daten immer selber aus dem Formular holen muss, dann musst du jedesmal die Klasse anfassen, oder das Formular in jeder Anwendung in der du mit dem COM-Port arbeiten willst integrieren. (macht beides keinen Spass)

Deshalb designt man in dem Fall die COM-Port klasse so, dass die Daten abgeholt werden und hingetragen werden. Das ermöglicht es, die COM-Port Klasse ohne Kenntnisse der umliegenden Applikation in beliebigen Anwendungen zu übernehmen.

Hier innerhalb eines Programmes von einer Klasse zur anderen mittels Timer oder gar Messages zu arbeiten - Sorry das wäre in meinen Augen übertrieben.

Was glaubst du, macht die VCL intern? Bzw. Was glaubst du, machen Programme wenn sie WinAPI basierend sind? Messages sind bei weitem nicht nur für Interprozesskommunikation gedacht. Messages sind zum Beispiel der einzige effiziente Weg (neben den Callbacks) ein eventgetriebenes System aufzubauen. Und alle GUI sind Eventgetrieben.

Beide Systeme (Callback und WM) haben vor und nachteile. Mal ist das Eine effizient, mal das andere.