Adressen von ListItems ändern sich

[Wormid]

Zitat von stahli:

Das passiert nur sporadisch und nur auf dem Kundenrechner?
Habt Ihr mal externe Probleme ausgeschlossen (Hauptspeicher und Betriebssystem)?

Ja leider, das passiert nur sporadisch. (Sporadisch = Nach einigen Stunden bis Tagen, ohne bisher erkennbares Muster).
Den Kundenrechner haben wir noch nicht ausgeschlossen - das werden wir aber baldmöglichst nachholen.
(RAM testen, ggfls. ganze Maschine tauschen). Allerdings verspreche ich mir da nicht sehr viel von, der Rechner ist der Gleiche wie vor dem "Update" - und da lief es (mit der alten Version) Problemlos.

Zitat von Uwe Raabe:

Steht OwnerData auf true? In dem Fall sollte ein Blick in die Methode TCustomListView.GetItem genügen, um zu verstehen, daß man besser keine Pointer auf TListItems speichert.

Sehr guter Hinweise, aber OwnerData ist überall auf false.

Zitat von Medium:

Welche Delphi Version war es, als es noch lief?
...
Werden die Adressen irgendwo vielleicht mal als Strings oder PChars angesprochen?

Vorher war es Delphi 2006.
Die üblichen Unicode-Problemchen hatte er bei der Umstellung auch, allerdings werden keine Adressen zu Strings konvertiert oder ähnliches.


Danke für die bisherigen Anregungen - bin jedoch noch offen für andere Ideen.

[jsp]

Hallo Wormid,

in solchen 'ab und zu' Fällen habe ich gute Erfahrungen mit
http://www.eurekalog.com/ gemacht.

Jörn

[Christian Seehase]

Moin Wormid,

seid ihr sicher, dass es an der Delphi-Version und nicht an der Betriebssystemversion liegt?
Immerhin wird ein ListView ja vom jeweiligen Betriebssystem zur Verfügung gestellt und ist keine generische VCL-Komponente.

[Wormid]

Zitat von Christian Seehase:

...seid ihr sicher, dass es an der Delphi-Version und nicht an der Betriebssystemversion liegt?

Die "alte" Version lief ja vorher auch auf dem gleichen Rechner beim Kunden. (*hust* War XP, ist XP).

Zitat von jsp:

...in solchen 'ab und zu' Fällen habe ich gute Erfahrungen mit
http://www.eurekalog.com/ gemacht.

Der Kollege vermeidet Exceptions mittlerweile, indem er die ListItems nicht mehr über die gespeicherte Referenz anspricht, sondern indem er sie jedesmal im ListView sucht, wenn er die Anzeige aktualisieren will.
Das brachte schon einiges an Verbesserung, leider aber noch nicht vollends. Und vor allem bleibt die Frage ("das Geschmäckle"), warum es auf einmal halt nicht mehr geht...

[himitsu]

Zitat von Wormid:

Die "alte" Version lief ja vorher auch auf dem gleichen Rechner beim Kunden. (*hust* War XP, ist XP).

Es kann aber auch sein, daß die alten Delphis eine alte API dieser Windows-Komponente benutzen. Beim Richedit gibt es mindestens 4 Versionen und da hat Delphi irgendwann auf eine neuere Version umgestellt, womit sich dort z.B. der Zeilenumbruch im RichEdit von #13#10 auf #13 änderte.

[Dejan Vu]

Schaut doch bitte einfach in den Quellcode von TListView und sagt dann, ob es irgend etwas mit der API oder dem OS zu tun haben kann. Ich hab hier nur mein olles D6 und da steht nicht drin, das die Instanzen vom OS verwaltet werden. Wäre auch lustig, wenn das OS plötzlich Delphi-Klasseninstanzen drauf hätte. Oder wenn Delphi von sich aus -ab und zu und nur beim Kunden- die Instanz vergisst.

[himitsu]

Hatte schon kurz reingesehn und auf die Schnelle nix gefunden.

Man könnte sich ja mal via TVirtualMethodInterceptor an eine/alle Item-Instanzen drangängen und vorallem schauen ob/wann das Destroy aufgerufen wird.

[Dejan Vu]

Also ich bin mir ziemlich sicher, das hier ein overrun-Problem besteht, d.h. es wird irgendwann irgendwo etwas überschrieben. Das íst vielleicht beim alten Delphi nicht aufgefallen, weil der Memory-Manager anders funktioniert hat, aber jetzt vielleicht.

Verwende vielleicht auch mal FastMM im FullDebugMode, schalte RangeCheck an, Overflowchecks auch usw. Du kannst ach Sentinel-Variablen einführen, oder die Referenz an anderer Stelle nochmals sichern und dann prüfen, ob die Referenzen noch identisch sind (Aber auch nur, wenn die vorherigen Maßnahmen nichts bringen)

Die ListViewItems werden vom Delphi-Control verwaltet. Über 'Items.Add' wird einfach nur ein neues TListItem instantiiert´. Das von Uwe beschriebene 'OwnerDraw'-"Problem" ist nur in "GetItem(Item : TLVItem)" vorhanden, und ob da ein Problem draus wird, würde ich bezweifeln. Denn dieses 'GetItem' hat mit dem Getter von 'Items[Index]' nichts zu tun, denn 'Items' ist eine Liste mit eigenem Getter und liefert einfach das Element an der Stelle zurück (soweit ich mich erinnere). Da auch die Liste an sich nicht verändert wird, sollte es daran eigentlich nicht liegen.

[Wormid]

Das mit dem FastMM werden wir mal angehen - Danke für den Tip!

[Uwe Raabe]

Zitat von Dejan Vu:

Das von Uwe beschriebene 'OwnerDraw'-"Problem" ist nur in "GetItem(Item : TLVItem)" vorhanden, und ob da ein Problem draus wird, würde ich bezweifeln. Denn dieses 'GetItem' hat mit dem Getter von 'Items[Index]' nichts zu tun, denn 'Items' ist eine Liste mit eigenem Getter und liefert einfach das Element an der Stelle zurück (soweit ich mich erinnere).

Stimmt zumindest in neueren Delphis nicht mehr: TListItems.GetItem ruft entweder Owner.GetItem (entspricht TCustomListView.GetItem) auf oder holt sich über ListView_GetItem(Handle, Item) den Pointer auf die Instanz aus Item.lParam. Insofern ist schon das Windows-Control irgendwie in die Speicherung der ListItems involviert.