Zur Laufzeit erzeugte Editierfelder

[KodeZwerg]

Zitat von runningsoft:

// Alternativ den Tag statt des Namens verwenden

Anstelle alternativ, immer so vorgehen, in allen events, ist mE. die beste Universallösung. Jedenfalls nutze ich es so in meinen dynamischen krams seitdem mich jemand aus der DP darauf gebracht hatte.

[himitsu]

In mindestens Win32 könnte man zwar auch zur Laufzeit ein Datenobjekt zu Integer casten und im Tag ablegen.
In der eigenen Datenklasse kann man dann ALLES speichern, was man will.
Aber im Formdesigner lässt sich sowas natürlich nicht nutzen.


Man kann die Komponenten ableiten und eigene Property einbauen.
Ist auch super, um mal bei allen gleichen Komponenten im später einen Bugfix zu integrieren oder Weiteres einzubauen.

Alternativ z.B. ein zusätzliches TDictionary<>, wo man Verknüpfungen zwischen Objekten (Objektzeiger) und irgendwas Anderem speichern kann.



Ach ja, INTEGER wurde eingefroren und wird im 64-Bit-Compiler nicht zu 64 Bit, was vorallem bei Casts zwischen Integer und Pointer/TObject knallen wird.

Aber Tag wurde zum Glück auf NativeInt geändert, womit es 64 Bit werden würde, damit solche bösen Castst nicht gleich fieß abrauchen, aber der Cast muß dafür natürlich auch den "richtigen" Typen verwenden.

[jziersch]

wenn Du sowieso Deine Edits zur Laufzeit erzeugts, kannst Du auch gleich eine TEdit Ableitung erzeugen, die zu der Aufgabenstellung passt. Dort kannst Du dann eine Referenz des passenden Typs verwalten und bist nicht auf die Tags beschränkt und brauchst auch nicht unbedingt Event handler zuzuweisen.

Edt:=TMySpecialEdit.Create(Self);

Wenn man Komponenten zur Laufzeit erzeugt, macht es keinen Sinn dort auch Namen zuzuweisen. Man riskiert nur Fehler, wenn Namen bereits existieren.

FindComponent brauchst Du nicht, wenn Du alle erzeugten Edits in einer TList<TMySpecialEdit> speicherts. Du kannst So auch einen Pool von Edits haben, deren Funktion Du nach Bedarf neu zuweisen kannst oder sie verstecken.

[himitsu]

dem stimme ich aber nicht ganz zu.
selbst wenn der Name nicht verwendet wird, so ist er beim Debuggen oft sehr hilfreich, z.B. kann man so an der Instanz in einem Eventhandler den Namen auslesen, was leichter zu verstehen ist, als irgendein ObjektZeiger.

aber ja, beim automatischen Erstellen muß man natürlich aufpassen, dass es keine Namenskonflikte gibt,
aber hier kann man z.B. den Namen aus einem Prefix und der Position in der Matrix gut generieren lassen.

[Blup]

Auch wenn ein Teil davon bereits erwähnt wurde, zähle ich das noch mal kurz mit auf:

Warum nicht eine Tabelle (Grid) für die Eingabe verwenden?

Wenn man Komponenten zur Laufzeit erzeugt, kann man denen auch passende Eigenschaften verpassen:

Delphi-Quellcode:

type
  TMyEdit = class(TEdit)
  private
    FPosition: TPoint;
  public
    property Position: TPoint read FPosition write FPosition;
  end;
{...}

Edt := TMyEdit.Create(Self);
Edt.Position.X := k;
Edt.Position.Y := i;
Edt.OnExit := ABCOnExit;
{...}

procedure TForm1.ABCOnExit(Sender: TObject);
begin
  k := TMyEdit(Sender).Position.X;
  i := TMyEdit(Sender).Position.Y;
  {...}
end;

Speichert man die Komponenten beim Erzeugen in einem Array, wird FindComponent nicht benötigt.

Delphi-Quellcode:

TForm1 = class(TForm)
private
  FMyEditABC: array of array of TMyEdit;
end;

Edt := TMyEdit.Create(Self);
FMyEditABC[k, i] := Edt;

[Kurt Wallander]

Glück auf!

Vielen Dank für die reichlichen Zuschriften. Habe mich an Ralfs Neumanns Vorschlag gehalten. Special thanks an ihn.
Aber gelegentlich tritt ein ganz anderes Problem auf. Beim Linken wird der Laufzeitfehler F2039: ...Ma-Orthogonalisieren.exe kann nicht erstellt werden.
Embacadero hat es offensichtlich nicht geschafft, das seit XE2 auftretende Phänomen auf den Leibe zu rücken. (Für Sezialisten: Die dcu-Dateien haben keinen zusätzlichen Punkt.)
Komischerweise werden andere Projekte anstandslos gelinkt - aber bei denen wird ja auch nichts geändert.



Viele Grüße
Kurt