Zur Laufzeit erstellte Komponenten im Array verwalten

[Rued]

Hallo!

Ich weise 13 zur Laufzeit erstellte RadioGroups einem Array[1..13] zu, um mir Findcomponent zu sparen. Ebenso verfahre ich mit 13 Checkboxen, die einem Array[1..13] zugewiesen werden. Bei den Checkboxen gibt es kein Problem, ich kann auf alle zugreifen. Bei den RadioGroups wird mit der 13. Zuweisung das erste Feld des Array eliminiert, so dass Array[1] nil ist. Anders formuliert, würde die Schleife bei 12 enden, würde der Zugriff auf alle dem Array zugewiesenen Komponenten funktionieren, mit Nummer 13 wird aber Komponente Nummer 1 "rausgekegelt". Nachtrag: Letzter Satz stimmt so nicht. Habe die Schleife jetzt `mal bis 12 gezogen, auch da wurde Array[1] mit der letzten Zuweisung "rausgekegelt".

Ich habe so etwas noch nicht erlebt. Dasselbe passiert übrigens auch, wenn ich das Array auf 14 dimensioniere. Bis zur Klärung habe ich mir so geholfen, dass ich Array[1] puffer und nach dem Durchlauf der Schleife dem Array[1] den Puffer zuweise.

Hat da jemand einen Tipp?

Gruß

Rüd

[himitsu]

Das Wichtigste: Wie sieht dein Code aus und wie soll dir jemand ohne das helfen können?

Hast du mal die Bereichsprüfung in den Projektoptionen aktiviert?

Und was sagt der Debugger, wenn du mal nach dem Wert schaust, während sich das Array langsam füllt?

[Dejan Vu]

<Glaskugel mode="on">
Die beiden Arrays liegen in der Deklaration hintereinander, Du vertust dich bei deinem Arrayindex um +1 und anstatt auf das letzte Element des ersten Arrays zuzugreifen, greifst Du auf das erste Element des zweiten Arrays zu:

Delphi-Quellcode:

var
  Array1 : Array [0..12] Of TFoo;
  Array2 : Array [0..12] Of TFoo;

begin
  Array1[13] := Bar; // Hier wird Array2[0] beschrieben!

</Glaskugel>

PS: Hör auf himitsu.

[Rued]

Das ist der betreffende Code, der mit der Krücke klappt. TFrfrTippFeld ist ein Frame, deren Komponenten über Findcomponent angesprochen werden.

Delphi-Quellcode:

var
  FMain: TFMain;
  PSpiele:array[1..11] of TPanel;
  Edits:array[1..11,0..3] of TEdit;
  RGTipps:array[1..11] of TRadioGroup;
  cbTipps:array[1..11] of TCheckBox;
implementation
...........
...........
procedure TFMain.FormCreate(Sender: TObject);
var
    FRA:TFrame;
    a,b:integer;
    RGPuf:TRadioGroup;
begin
 for a := 1 to 11 do begin

 FRA := TFrfrTippFeld.Create(FMain);

   with FRA do begin
   left := 0;
   top := 10+ (a-1)*51;
   name := 'frSpiel'+inttostr(a);
   height := 45;
   width := 900;
   end;
   FRA.parent := PFeld;
   PSpiele[a] := TPanel(Fra.findcomponent('PSpiel'));
   PSpiele[a].Color := MitFarben[1];
   TLabel(Fra.findcomponent('LNr')).Caption := 'Spiel '+inttostr(a);
   for b := 0 to 4 do Edits[a,b] := TEdit(Fra.findcomponent('Edit'+inttostr(b)));
   RGTipps[a] := TRadioGroup(Fra.findcomponent('RGTipp'));
   cbTipps[a] := TCheckBox(Fra.findcomponent('cbTippen'));
   if a = 1 then RGPuf := RGTipps[a];                          //Krücke Teil 1
end;
   RGTipps[1] := RGPuf;                                       ////Krücke Teil 2  

...........
...........

Zitat:

Und was sagt der Debugger, wenn du mal nach dem Wert schaust, während sich das Array langsam füllt?

Wie ich schrieb, klappt alles bis zur letzten Zuweisung. Heißt, das Array füllt sich korrekt - dann kommt die letzte Zuweisung, auch die klappt, aber dann ist RGTipps[1] = nil.

Gruß

Rüd

[DeddyH]

Zitat:

Delphi-Quellcode:

Edits:array[1..11,0..3] of TEdit;

Zitat:

Delphi-Quellcode:

for b := 0 to 4 do Edits[a,b] := TEdit(Fra.findcomponent('Edit'+inttostr(b)));

Ich würde an Deiner Stelle immer mit High() und Low() arbeiten, dann kann Dir so etwas nicht passieren. Außerdem ist es kein Fehler, die Bereichsprüfung zu aktivieren, aber das wurde IIRC bereits erwähnt.

[baumina]

Auf den ersten Blick :

Delphi-Quellcode:

var
  Edits:array[1..11,0..3] of TEdit;     // <- 0..3

...........
...........
   // aber 0..4 -> PENG
   for b := 0 to 4 do Edits[a,b] := TEdit(Fra.findcomponent('Edit'+inttostr(b)));
...........
...........

EDIT : Hach, immer isser schneller *wein

[DeddyH]

Hast aber lange geblickt, wie? :zwinker:

[baumina]

Irgendwas hat an meinem Text nicht gestimmt, der hat immer behauptet dass mein Text zu kurz sei und dann musst ichs x-mal abändern *schnief ... wertvolle Zeit verloren dadurch.

[DeddyH]

Die Welt ist eben hart, aber ungerecht. Nächstes Mal bist Du dann wieder schneller *tröst*

[himitsu]

Und am Ende läuft es auf Eines hinaus ... hätte man mal probehalber die Bereichsprüfung aktiviert
oder sich zumindestens mal die Array-Bereiche mit den Zugriffen verglichen, dann wäre das Problem "sofort" aufgefallen.
Man hätte auch mal mit dem Debugger schauen können und dann wäre da eventuell aufgefallen, daß sich der Wert beim Zugrüff auf das andere Array ändert.


Codeformatierung = na ja
Und warum gibt es hier so viele globale Variablen? (die gehören doch wohl eher ins Private der Form)

@baumina: alle Zitate (qoute) wegdenken, Leerzeichen wegdenken und der Rest muß eine gewisse Länge haben.
Und wenn der Rest auch noch nur aus Großbuchstaben besteht, dann wird alles automatisch klein gemacht. :wall: (selbst wenn es sich um eine großgeschriebene Abkürzung handelt)

[baumina]

Zitat:

Zitat von himitsu (Beitrag 1269434)

@baumina: alle Zitate (qoute) wegdenken, Leerzeichen wegdenken und der Rest muß eine gewisse Länge haben.
Und wenn der Rest auch noch nur aus Großbuchstaben besteht, dann wird alles automatisch klein gemacht. :wall: (selbst wenn es sich um eine großgeschriebene Abkürzung handelt)

Ich hatte versehentlich innerhalb von QUOTE meinen Text, deswegen meinte der dass ich ja gar nix geschrieben hätte ... ist mir nun auch eingefallen wo mein Fehler war (der ja wie auch hier zu 99% vor dem Bildschirm sitzt).

[Rued]

Herzlichen Dank Euch!

Die Bereichsüberprüfung war in der Tat ausgeschaltet. Die hätte es mir natürlich angezeigt. Tut mir leid, Euch damit aufgehalten zu haben.

Gruß

Rüd

[Dejan Vu]

Nur Schattenparker seriöse Entwickler schalten die Bereichsprüfung ein.

Ich habe das z.T. auch erst nach Monaten gemacht, nur, um mir zu beweisen, wie toll meine SW ist. Rumms. Volles Brot gegen die Wand gefahren.

[himitsu]

Jaaaa,

da wo absichtlich mit Überläufen und Bufferoverflows gearbeitet wird, dort sollte man sowas nicht aktivieren, bzw. immer lokal deaktiveren,
aber ansonsten hat man eigentlich ein Problem, wenn es dabei knallt. :stupid:


z.B. wildes rumgepointere und Hash-Funktionen

[schöni]

Zitat:

Zitat von himitsu (Beitrag 1269504)

Jaaaa,

da wo absichtlich mit Überläufen und Bufferoverflows gearbeitet wird, dort sollte man sowas nicht aktivieren, bzw. immer lokal deaktiveren,
aber ansonsten hat man eigentlich ein Problem, wenn es dabei knallt. :stupid:


z.B. wildes rumgepointere und Hash-Funktionen

Solcher Programmierstil dürfte nur in Hogwarts funktionieren, aber selbst dort ist das die ganz hohe Schule der Programmierung. Dort gibt es dann auch zum Debuggen die richtigen Glaskugeln. :lol:

[Dejan Vu]

Einfach verbieten! Teeren, Federn und Kieselsteinigen sollte man diese Programmierer.

[himitsu]

Nja, wenn man z.B. das "Verhalten" eines Überlaufs geziehlt ausnutzt und das in dem Code auch klar ersichtlicht oder zumindestens bekannt ist und wenn dort der Compiler auch entsprechend eingestellt wird (nötige Compilerschalter "lokal" in-/aktiv), dann ist das IMHO eigentlich OK so.
Wozu noch explizite Typecasts oder weitere "unnötige" Rechenschritte, wenn der die CPU das "automatisch" erledigt, vorallem bei Codes die ja recht schnell sein sollen.

Der Code muß dann aber auch die richtigen Typen verwenden, damit das nicht irgendwann kaputt gehen könnte, wenn man die Plattform ändert,
aber sowas sollte sowieso immer überall richtig gemacht werden. :roll: