Discussion:
[D4] TListView bringt Programm zum Absturz
(zu alt für eine Antwort)
Michael Landenberger
2017-02-06 10:15:27 UTC
Permalink
Hallo,

ich habe hier ein mit Delphi 4 erstelltes 32bit-Programm. Dieses enthält
einige Formulare mit TListView-Komponenten mit ViewStyle = vsReport. Das
Programm läuft auf allen derzeit verbreiteten Windows-Versionen bis
einschließlich Windows 10 einwandfrei, mit einer einzigen Ausnahme: Windows 7
64bit. Nur unter diesem Betriebssystem friert das Programm reproduzierbar ein,
wenn eines der Formulare mit einem TListView geöffnet wird. Das Formular wird
zwar noch angezeigt, aber das ListView ist leer und es fehlen auch die
Spaltenköpfe. Auf Benutzereingaben reagiert das Programm dann nicht mehr, man
kann es nur noch im Task-Manager abschießen. Ich habe daraufhin die
Eigenschaft "ShowColumnHeaders" des ListViews mal testweise auf "False"
gesetzt, worauf das Programm nicht mehr abstürzte. Offenbar passiert der Crash
beim Zeichnen der Spaltenköpfe.

Ich habe daraufhin den Programmcode durchforstet, kann aber nichts finden, was
den Absturz verursachen könnte. Erstaunlich ist, dass das Programm auf
sämtlichen 32bit- *und* 64bit-Versionen von Windows Vista, 8(.1) und 10 sowie
unter Windows 7 32bit (und sogar noch unter einem 32bit-XP) einwandfrei läuft,
nur eben nicht auf Windows 7 64bit.

Ich habe testweise mal eine eigene, von TWinControl abgeleitete
ListView-Komponente probiert, die hat das Problem nicht.

Ist irgendein Bug in den TListView- oder TListColumn-VCL-Komponenten bekannt,
der diesen Absturz verursachen könnte? Eine Suche im Netz hat leider keine
brauchbaren Hinweise geliefert. Auch im VCL-Quelltext ist mir nichts
aufgefallen.

Gruß

Michael
Björn Schreiber
2017-02-06 12:53:34 UTC
Permalink
Post by Michael Landenberger
ich habe hier ein mit Delphi 4 erstelltes 32bit-Programm. Dieses enthält
einige Formulare mit TListView-Komponenten mit ViewStyle = vsReport. Das
Programm läuft auf allen derzeit verbreiteten Windows-Versionen bis
einschließlich Windows 10 einwandfrei, mit einer einzigen Ausnahme: Windows 7
64bit. Nur unter diesem Betriebssystem friert das Programm reproduzierbar ein,
wenn eines der Formulare mit einem TListView geöffnet wird.
Verwendest du zufällig den ThemeManager von Mike Lischke? In
Verbindung mit einem entsprechenden (externen) Manifest?

Wir haben bei unseren Kunden ähnliche Beobachtungen gemacht.
Entsprechende Dialoge werden nicht korrekt dargestellt oder aber es
tritt ein nicht näher spezifizierter Win32-Fehler auf.

Bei unseren Anwendungen reicht als Abhilfe aus, die externe
Manifest-Datei zu entfernen und damit die Verwendung der alten Common
Controls Bibliothek zu erzwingen.
Ich erinnere mich momentan nur an Rechnern mit Windows 7, die das
Problem aufzeigten. Allerdings ist dies offensichtlich nicht
ausschlaggebend, da unsere Anwendungen auf zahlreichen weiteren Windows
7 Installationen problemlos laufen. Ich vermute eine Wechselwirkung mit
einer weiteren Systemkomponente, ggf. dem Grafikkartentreiber.


hth,
Björn
--
Björn Schreiber
DRIGUS GmbH
Michael Landenberger
2017-02-06 19:11:46 UTC
Permalink
Verwendest du zufällig den ThemeManager von Mike Lischke? In Verbindung
mit einem entsprechenden (externen) Manifest?
Den Theme Manager verwende ich nicht. Ein Manifest allerdings schon,
allerdings kein spezielles. Es stammt noch aus XP-Zeiten und dient dazu, die
Common Controls im jeweils aktuellen Stil darzustellen. Das Manifest liegt
aber nicht in einer separaten .manifest-Datei, sondern es wird mittels
$RES-Direktive als Ressource in die EXE eingebunden.

Jedenfalls danke für den Hinweis. Ich kann ja mal das Manifest aus der EXE
entfernen und sehen, was passiert. Schlimmstenfalls baue ich halt meine eigene
ListView-Komponente ein, die keine Probleme macht.

Erstaunt bin ich aber nach wie vor darüber, dass das Programm wirklich nur
unter W7 64bit abstürzt. Unter W7 32bit läuft es genauso einwandfrei wie unter
den 32- *und* 64bit-Varianten aller anderen derzeit verbreiteten
Windows-Versionen.

Gruß

Michael
Stefan M. Huber
2017-02-07 07:42:13 UTC
Permalink
Post by Michael Landenberger
Verwendest du zufällig den ThemeManager von Mike Lischke? In Verbindung
mit einem entsprechenden (externen) Manifest?
Den Theme Manager verwende ich nicht. Ein Manifest allerdings schon,
allerdings kein spezielles. Es stammt noch aus XP-Zeiten und dient dazu, die
Common Controls im jeweils aktuellen Stil darzustellen. Das Manifest liegt
aber nicht in einer separaten .manifest-Datei, sondern es wird mittels
$RES-Direktive als Ressource in die EXE eingebunden.
Jedenfalls danke für den Hinweis. Ich kann ja mal das Manifest aus der EXE
entfernen und sehen, was passiert. Schlimmstenfalls baue ich halt meine eigene
ListView-Komponente ein, die keine Probleme macht.
Erstaunt bin ich aber nach wie vor darüber, dass das Programm wirklich nur
unter W7 64bit abstürzt. Unter W7 32bit läuft es genauso einwandfrei wie unter
den 32- *und* 64bit-Varianten aller anderen derzeit verbreiteten
Windows-Versionen.
Du könntest auch versuchen, das Programm im Kompatibilitätsmodus
auszuführen.

Stefan
Michael Landenberger
2017-02-07 18:35:31 UTC
Permalink
Post by Stefan M. Huber
Du könntest auch versuchen, das Programm im Kompatibilitätsmodus
auszuführen.
Das würde ich nur machen, wenn wirklich gar nichts mehr hilft ;-) Ich war
nämlich immer stolz darauf, dass meine Programme kompatibel zu allen
Windows-Versionen waren, und das ohne Kompatibilitätsmodus.

Nachdem ich festgestellt habe, dass ein Entfernen des Manifests (wie bereits
geschrieben als Ressource in der EXE eingebunden) nichts gebracht hat, habe
ich die TListViews jetzt durch eine eigene Komponente ersetzt. Jetzt läuft's
wieder. Und zwar unter allen Windowsen von XP bis 10 in 32 und 64bit.

Gruß

Michael

Björn Schreiber
2017-02-07 08:15:02 UTC
Permalink
Post by Michael Landenberger
Erstaunt bin ich aber nach wie vor darüber, dass das Programm wirklich nur
unter W7 64bit abstürzt. Unter W7 32bit läuft es genauso einwandfrei wie unter
den 32- *und* 64bit-Varianten aller anderen derzeit verbreiteten
Windows-Versionen.
Ich hatte ganz vergessen zu erwähnen, dass das Problem in unseren
Anwendungen nur dann auftrat, wenn der Anwender explizit das klassische
Design unter Windows aktiviert hatte. Das Problem verschwand, wenn auf
die Standarddarstellung von Windows umgeschaltet wurde.
Deswegen hatten wir uns auch mit dem Löschen der externen
Manifest-Datei begnügt, an der Darstellung ändert sich dadurch ja eh nichts.


Gruß,
Björn
--
Björn Schreiber
DRIGUS GmbH
Loading...