TStringList - Zugriff auf property

[NicoleWagner]

Zitat von hoika:

Hallo,
aha, wir kommen näher.

Es wird also sortiert.

"div Zeilen" nützt uns nichts, bitte lauffähigen Code hier reinstellen.
SL_SUB.Add('x');
SL_SUB.Add('y');

Es fehlt der Code von StringListSortComparefn2.


1. Was passiert eigentlich, wenn Du StringListSortComparefn2 mal auskommentierst?
2. Hast Du mal einen Brealpoint auf die Zeile SL_SUB.Free; gesetzt und dann deine Watchpoints angesehen.
3. Nimm mal alle anderen Watchpoints raus.

Compare ist raus. Und auch alle anderen Zeilen davor.
Es wird immer seltsamer!
Ich habe einen Screenshot von dem Restcode gemacht.

https://www.dropbox.com/s/7hkigwg2tc...range.png?dl=0

Also ich bin mit meiner Weisheit am Ende.
Vor vielen, vielen Jahren hatte ich mal so einen "Fehler". Nach einigen Wochen fand ich dann, dass im interface Teil ein Strichpunkt irregulär war. Doch so etwas sehe ich heute nicht. Oder ein anderes mal, auch lange her... da hatte ich eine Variable, die den Schlusskurs enthielt, "close" genannt (reserviertes Wort). Bin mittlerweile für jegliche innovative Idee offen. Insbesondere, wie man Code aus einem Monsterprojekt, das jahrzehntelang entwickelt wurde und komplex vernetzt ist, zum Debug extrahiert...

Ich weiß nur, dass TCheckList Box in meiner Delphi XE 3 Version einen Bug ab Werk hat. Dieser Bug ist ebenfalls ein Listenzugriff. Doch "Schuldzuweisung" nützt mir nichts! Ich muss meinen Code irgendwie zum Laufen bringen.
Hat jemand eine Idee, wie ich die Werte, die stimmen, auslesen kann? (womit die Frage wieder bei meinem originalen Posting ist)

[Uwe Raabe]

Was ist denn jetzt der Fehler? Wir sehen hier nur das "inaccessible value" im Watch-Fenster. Was kommt denn im ShowMessage an?

Ich habe das jetzt hier mal in einem simplen Button-Click mit XE3 nachprogrammiert und da funktioniert sowohl das ShowMessage als auch die Anzeige im Watch-Fenster.

Kann es sein, daß du irgendwelche Plugins oder Komponenten installiert hast, die dieses auslösen? Klappt es in einer frischen Delphi-Installation?

Passiert das nur bei dieser einen Stringliste SL_SUB oder auch bei anderen?

Wie sieht es aus, wenn due SL_SUB umbenennst?

[Fritzew]

Kann es sein das Du irgendwo Deinen Stack überschreibst?
Stell doch mal Deine lokalen Variablen um also anstatt:

Delphi-Quellcode:

var
   SL, SL_Waren, SL_SUB, SL_Waren2: TStringList;

zu so etwas:

Delphi-Quellcode:

var
   SL: TStringList;
   SL_Waren: TStringList;
   SL_SUB: TStringList;
   SL_Waren2: TStringList;

Dann kannst Du auch noch die Reihenfolge ändern.
Stelle mal Dein SL_SUB an den Anfang

Delphi-Quellcode:

var
  SL_SUB: TStringList;
   SL: TStringList;
   SL_Waren: TStringList;
   SL_Waren2: TStringList;

was ist dann?
sind alle lokalen Variablen sinnvoll initialisiert?

z.B:

Delphi-Quellcode:

begin
 // nur als Beispiel
  SL := nil;
  SL_Waren := nil;
  SL_SUB := nil; 
  SL_Waren2 := nil;

[Rolf Frei]

Kann mich den Vorrednern nur anschliessen. Habe folgendes in XE3 kopmpiliert und da läuft alles wie es soll.

Code:

procedure TForm1.FormCreate(Sender: TObject);
var
  SL_SUB: TStringList;
  Anzahl: Integer;
  I: Integer;
begin
 {$O-}
  Anzahl := 10;

  SL_SUB := TStringList.Create;
  
  for I := 0 to Anzahl  do
  begin
    SL_SUB.Add(IntToStr(I));
  end;

  ShowMessage(SL_SUB.Strings[0]);   // In der Watchlist wird mir hier der korrekte Wert '1' angeziegt

  SL_SUB.Clear;   

  SL_SUB.Free;
end;

Allerdings solltest du solche Codekonstrukte immer in einen Try/Finally Block packen. Also so:

Code:

procedure TForm1.FormCreate(Sender: TObject);
var
  SL_SUB: TStringList;
  Anzahl: Integer;
  I: Integer;
begin
 {$O-}
  Anzahl := 10;

  SL_SUB := TStringList.Create;
  try

    for I := 0 to Anzahl  do
    begin
      SL_SUB.Add(IntToStr(I));
    end;

    ShowMessage(SL_SUB.Strings[0]);

    SL_SUB.Clear;

  finally
    SL_SUB.Free;  
  end;
end;

[NicoleWagner]

Danke allen hier, die noch Kampfgeist haben!
(dass jemand mit der Zuweisung von "nil" initialisieren will, vergessen wir)

Ich habe jetzt das umgesetzt:
- das TStringList in einer extra Zeile deklariert
- die Var umbenannt von SL_SUB in SL_Untergruppe
- try finally benutzt (das "immer" zu tun, kostet zuviel Performance), doch hier war es wirklich ein Ansatzpunkt, der etwas änderte:

Ich beobachte zwei Effekte:

1) Die ShowMessage Ausgabe funktioniert auf einmal korrekt(!!), - für beide Testausgabezeilen.
2) Der finally Block wird abgearbeitet.

Also ein kleines Quentchen Trost.
Doch noch immer crasht mir die komplette IDE, wenn ich meinen Wert weiterverarbeiten möchte.
Und noch immer sehen die Werte irritierend aus.
Wieder sagt ein Bild mehr als 1000 Worte.
https://www.dropbox.com/s/zjvi6azn9b..._Hope.png?dl=0

[Fritzew]

ok das nil war als Beispiel ungünstig gewählt,
mir ging es darum dass Deine lokalen Variablen die ja auf dem Stack liegen erst mal initialisiert sind. Initialisiert in dem Sinn nicht mit dem Inhalt des Stacks sondern klar definiert. Und da zählt auch Nil dazu..
Da Du aber ja immer nur Bilder zeigst, ohne den ganzen Sourceblock.........

Ich behaupte immer noch das Du irgendwo den Inhalt des Stack überschreibst...

Mach mal Spasseshalber zwischen Deine lokalen Variablen jeweils ein Dummy

z.B:

Delphi-Quellcode:

var
   SL: TStringList;
   Dummy1 : int64;
   SL_Waren: TStringList;
  Dummy2 : int64;
   SL_SUB: TStringList;
  Dummy3 : int64;
   SL_Waren2: TStringList;
Dummy4 : int64;

Initialisieren

Delphi-Quellcode:

begin
 Dummy1 :=0;
 Dummy2 :=0;
 Dummy3:=0;
 Dummy4:=0;
 

end;

So solltest Du eventuell an diesen Variablen im Debugger etwas sehen...

[Neutral General]

Zitat von NicoleWagner:

- try finally benutzt (das "immer" zu tun, kostet zuviel Performance), doch hier war es wirklich ein Ansatzpunkt, der etwas änderte:

Falls dein PC 20+ Jahre alt ist, dann mag das vielleicht stimmen, aber wenn du dir um die Performance von try-finally heutzutage noch Gedanken machst,
dann machst du etwas falsch. Das Risiko try-finally nicht zu benutzen ist ein vielfaches höher als das Quäntchen "Performance" was dir verloren geht.

Was deinen Code angeht wäre es glaube ich jetzt ganz gut wenn wir einen größeren Überblick über den Code hätten.
So wie es aussieht liegt der Fehler tiefer.
Falls möglich wäre es am besten wenn du deinen ganzen Code mal hochladen würdest.

[NicoleWagner]

an Michael, danke für Deine Antwort,zu "ganzen Code hochladen": Du sprichst von einer ziemlich großen eingebundenen DB und deutlich über 100 Units.
Eine "einfache Version" an Code siehst Du bereits, den ganzen Code willst Du, glaube mir, NICHT sehen, smile.
Wenn Du die umfangreichen DB-Query-Abfragen noch in stochastische Prozesse schickst, dann merkst Du ein "try" mehr oder weniger auch dann, wenn Du so einen schnellen Computer hast wie ich. Alte PCs haben da noch tagelang gerechnet daran.


Fritz, ad Deklarationszeilen einschieben:
leider nein, da sehe ich diesmal nichts Neues.
https://www.dropbox.com/s/a98u61sqyo...Dummy.png?dl=0

Dass etwas Gröberes schief läuft im Speicher, das ist klar. Mit "Überschreiben" wird es schon etwas haben, doch was? Es sieht alles regulär aus. Ein Kollege hier (danke!) ließ das ja durchlaufen und es klappte. Bei mir klappt es nicht. Es muss etwas sein, das entweder in meinem Code passiert oder in XE 3 oder in dem Zusammenspiel der beiden.

Bist Du gut in Assembler? Ich leider ganz schlecht, doch man müsste, wenn man weiß wie, die Speicherzugriffe auswerten können, die intern schief laufen.
Oder durch die interne Delphi Unit surfen. Allerdings fürchte ich, dass ich da stundenlang klicke und der Fehler im Grunde an anderer Stelle passiert, als ich denke. Weil ich nur auf die Auswirkugen davon klicken würde.

[Fritzew]

Hallo Nicole,
ok, klingt alles schwierig.

DataBreakpoints sagen Dir etwas?
Die könnten helfen,
oder bau Dir ein Logging ein.

Ein hilfsvariable Pointer auf Deine SL_SUB;


Nach jedem Aufruf versuche den Inhalt von z.B SL_SUB[0] zu loggen;
// Pseudocode
Sowas wie Loger (Pointer Helper, Pointer SL_SUB, Inhalt SL_SUB[0]);

Kanst mir auch ne PM schicken.

[Tyrolean]

Hallo!
Probier doch mal eine Ableitung von TStringlist zu machen und dann in diesem Destroy einen Haltepunkt.
Und SL_SUB ist dann von deinem TMyStringlist
Dann solltest du erkennen können ob dein Stringlist irgendwo zerstört wird..
Gruß
Günter