wert "durchreichen" ?

[stahli]

Ich will auch mal noch zu Missverständnissen beitragen... :wink:

Wenn Du eigene ScrollBoxen verwendest, könntest Du eine Eigenschaft UsesEdit einrichten und der Dein Edit zuweisen:

MyScrollBox := TMyScrollBox.Create(Self);
MyScrollBox.UsesEdit := Edit1;

Innerhalb der Scrollboxereignisse kannst Du dann auf UsesEdit zugreifen.

Alternativ könnte man eine globale Variable nutzen, wenn man mit den Protesten der Profi-Gemeinde leben kann.

[ConnorMcLeod]

Sorry, wenn ich das falsch verstehe, aber meine Idee:
Pseudocode!

Delphi-Quellcode:

procedure GruppenButtonWurdeGeklickt(const AEditText: string);
var
  li: integer;  // Schleifenzaehler
  NewScrollBox: TScrollBox;
begin
  NewScrollBox := CreateProductScrollboxWithButtons;
  for li := 0 to NewScrollBox.ComponentCount-1 do
  begin
    if (NewScrollBox.Components[li] is TProductButton) then
    begin
      TProductButton(NewScrollBox.Components[li]).StringProperty := AEditText;
    end;
  end;
end;

[shmia]

Nur mal so ganz grundsätzlich:
Das Ableiten von Controls (visuelle Komponenten) ist von Ausnahmefällen abgesehen absolut nicht empfehlenswert.
Man kann Objekte in zwei Kategorien einteilen:
* unabhängig von der Anwendung
* spezialisiert auf die Anwendung
Controls (bzw. Komponenten allgemein) sind wie Legosteine; man kann sie unverändert in vielen versch. Projekten einsetzen.
Daneben gibt es aber auch eigene Klassen (sog. Business-Objekte), die ganz speziell auf die Anwendung zugeschnitten sind.

Was hier in deinem Projekt wahrscheinlich fehlt ist eine Artikel-Klasse.
Diese Objekte tragen die Informationen (z.B. Artikelnummer, Beschreibung, DB-Schlüssel, Status,...) und werden zwischen den Formularen ausgetauscht.
Wenn du diese Artikel-Klasse in eine eigene Unit packst, dann kannst du Artikelobjekte problemlos zu versch. Formularen durchreichen.
Neben einer Artikel-Klasse wirst du möglicherweise weitere Klassen benötigen: Artikelliste, Artikelgruppe.

Die einzigen Komponenten, die anwendungsspezifisch abgeleitet werden dürfen sind: TForm und TFrame.

[ConnorMcLeod]

Zitat:

Zitat von shmia (Beitrag 1096021)

Was hier in deinem Projekt wahrscheinlich fehlt ist eine Artikel-Klasse.

Siehe TProductButton und TProductButton.StringProperty ;-)

[khh]

Zitat:

Zitat von shmia (Beitrag 1096021)

Nur mal so ganz grundsätzlich:
Das Ableiten von Controls (visuelle Komponenten) ist von Ausnahmefällen abgesehen absolut nicht empfehlenswert.
Man kann Objekte in zwei Kategorien einteilen:
* unabhängig von der Anwendung
* spezialisiert auf die Anwendung
Controls (bzw. Komponenten allgemein) sind wie Legosteine; man kann sie unverändert in vielen versch. Projekten einsetzen.
Daneben gibt es aber auch eigene Klassen (sog. Business-Objekte), die ganz speziell auf die Anwendung zugeschnitten sind.

Was hier in deinem Projekt wahrscheinlich fehlt ist eine Artikel-Klasse.
Diese Objekte tragen die Informationen (z.B. Artikelnummer, Beschreibung, DB-Schlüssel, Status,...) und werden zwischen den Formularen ausgetauscht.
Wenn du diese Artikel-Klasse in eine eigene Unit packst, dann kannst du Artikelobjekte problemlos zu versch. Formularen durchreichen.
Neben einer Artikel-Klasse wirst du möglicherweise weitere Klassen benötigen: Artikelliste, Artikelgruppe.

Die einzigen Komponenten, die anwendungsspezifisch abgeleitet werden dürfen sind: TForm und TFrame.

klingt logisch und gut,

ich danke euch