Eindeutigen Name für Frame durch anhängen einer Nummer finden

[Peter-Pascal]

Hallo,

ihr kennt sicherlich das Problem, wenn man mehre gleiche Frames auf eine Form oder anderem Frame setzt, meldet Delphi einen Fehler, dass dieser Frame bereits existiert. Es benötigt einen eindeutigen Namen, den man durch anhängen einer Nummer erreicht. Soweit so gut, wenn Delphi auf einer Form Nummern vergibt für Komponenten, wie TEDit oder TLabel, dann füllt Delphi auch wieder die Lücken, die durch Löschen entstanden sind. Ich wollte es so machen, wie Delphi es macht, konnte es nicht finden oder habe den Code nicht begriffen. Weiß jemand wie Delphi die Nummerierung lückenlos schafft?

Mein Versuch:

Delphi-Quellcode:

function TFrameBuchenBank.findFreeNumber: integer;
var
  I,J,Zahlen: Integer;
  Frame: TFrameBuchenBankDetail;
  ZahlenArray: TArray<string>;
  Fund: boolean;
begin

  for I := 1 to ScrollBoxKontierZeilen.ComponentCount do
  begin

    ScrollBoxKontierZeilen.EnumObjects(
    function (aObject: TFMXObject) : TEnumProcResult
    var Anhalten: boolean;
    begin
      Anhalten:= false;
      if aObject is TFrameBuchenBankDetail then
      begin
        Frame:= aObject as TFrameBuchenBankDetail;
        Fund:= Frame.NameNr = I;
        Anhalten := Fund;
      end;
     if Anhalten
      then Result:= TEnumControlsResult.Stop
      else Result:= TEnumControlsResult.Continue
    end
    );

  if not Fund then exit(I)
  end;

  Result:= ScrollBoxKontierZeilen.ComponentCount + 1
end;

Auch da habe ich lange dran herumexperimentiert.

Danke für eure Mühe.
Gruß Peter

[Uwe Raabe]

Brauchst du denn die Namen für irgendetwas? Andernfalls kannst du auch einfach den Namen des Frames auf einen Leerstring setzen. Mehrere Komponenten ohne Namen sind nämlich erlaubt.

[Peter-Pascal]

Hallo Uwe,

danke für Deine Antwort.

Nein, die Namen brauche ich nicht.

Das heißt, ich könnte

Delphi-Quellcode:

 Frame.Name := EmptyStr;

setzen?
Mehrere sind erlaubt, schreibst Du, kannst Du ungefähr sagen wie viele?

Die Frames nehmen in einem zusammengesetzten Buchungssatz jeweils ein Konto entgegen. Ich wollte zwar keine Begrenzung einbauen, aber bei einer genügenden Anzahl, wäre es vermutlich die einfachste Variante.

Gruß Peter

[himitsu]

Ja.
Warum nicht

Delphi-Quellcode:

:= '';

Irgendwie verstehe ich nicht, warum jemand auf die Idee kommt diese blöde "Variable" zu benutzen.
(du willst nicht wissen wie viel Spaß es macht, wenn sie mal ausversehn verändert wurde)

Egal wieviele. (bis der Speicher überläuft)
Ein "Name" muß pro Owner "eindeutig" sein, wenn er gesetzt ist.

[Peter-Pascal]

Danke Himitsu,

wenn ich den Namen auf Leerstring setzen kann und dann nur der Speicher die Grenze ist, hilft es nicht nur, sondern vereinfacht die Sache kolossal.

Zitat:

Irgendwie verstehe ich nicht, warum jemand auf die Idee kommt diese blöde "Variable" zu benutzen.

Sieht schicker aus.

Zitat:

(du willst nicht wissen wie viel Spaß es macht, wenn sie mal ausversehn verändert wurde)

Doch das kann ich mir vorstellen, solange ich nicht Opfer bin. Ich weiß jetzt aber worauf ich ggf. zu achten haben.

Danke noch mal Himitsu und Uwe.

Gruß Peter

[himitsu]

Die Window-Handles (GDI) sind auch noch ein Limit, sind inzwischen wohl bei 65.536, also alle "Windows", was Forms, Frames, Panels, Edits, Buttons, aber auch Bitmap, Canvas, Font usw. sind.
https://learn.microsoft.com/en-us/wi...fo/gdi-objects

[Peter-Pascal]

Danke Himitsu,

diese Grenze werde ich wohl bestimmt nicht erreichen.
Wie oben geschrieben dienen die Frames, um einen Teilbuchungssatz entgegenzunehmen. Ohnehin muss ich mir noch überlegen, ob ich die Teilbuchungssätze auf maximal 100 begrenze. Bei Lohn kann schon ein sehr umfangreicher Buchungssatz entstehen.

Gerade bin ich dabei, den Code umzuschreiben, um die Frames ohne Namen zu nutzen. Soweit ich das sehe, erleichtert es einiges.

Gruß Peter

[himitsu]

Wie groß aufwändig ist denn der Frame?

Vielleicht wäre die TControlList eine Überlegung wert.
https://docwiki.embarcadero.com/RADS...olList_Control
https://www.youtube.com/watch?v=PfHV9AhV2NM


@Uwe: Ja, die ListBox im FMX ist dagegen besser.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1533203)

Vielleicht wäre die TControlList eine Überlegung wert.

Da ist eher die Frage, welche Controls auf dem Frame verwendet werden.

[Peter-Pascal]

So richtig weiß ich nicht, was Du mit Größe meinst. Die *.pas hat 12 KB und die dazugehörige *.fmx noch mal 8 KB.

Das Frame enthält einige Komponenten und es können noch mehr werden.

Vielleicht hilft Dir ein Bild weiter, die Größe einzuschätzen:

Ich nutze fmx.

Die Frames sammelt einer TScrollBox.

TListBox habe ich auch ausprobiert, hatte Schwierigkeiten Code in jedes einzelne Item zu bekommen. Vielleicht meine Unerfahrenheit.
Die Frames enthalten noch 360 Zeilen Code, wobei möglicherweise sich das noch um 50 bis 100 Zeilen kürzen läßt. Kann auch mehr werden, ich versuche so viel wie möglich die Frames selbst erledigen zu lassen. Trotzdem greift es auf ein Businesstool zu und anschließend ein Model
.
In Abhängigkeit des Kontos werden unterschiedliche Funktionen ausgeführt: u.a. Umsatzsteuer und Kategorie. Im Gegensatz zu anderen Buchhaltungsprogrammen habe ich bei den Konten die Sortierung nach Kategorien eingebaut.

Grundsätzlich halte ich die ListBox von fmx für eine tolle Komponente und habe sie für andere Aufgaben vorgesehen. Das Schöne an der Listbox ist, dass sie auch längs funktioniert.
In der Fibu habe ich für alles, was ich Listen brauche ListView genommen.

[himitsu]

Groß = Was so alles drauf liegt, wie Uwe schon sagte ist TControlList (VCL) "etwas" eingeschränkt.

FMX weiß ich's grade nicht (bzw. beim Test grade zu doof angestellt),
aber mir war so, als wenn man dort in der TList nahezu alle Komponenten reinbekommt.


Also wenn alles die "selben" Frames sind,
dann dort ein Vorlage-Item im Designer zusammenklimpern und das wird dann ItemCount-mal zur Laufzeit vervielfältigt.
Im FMX dann noch via LiveBinding an eine TList<> oder Dataset hängen und von da automatisch mit Daten füllen lassen.