Tweet
Hallo an alle, die TImageList mit Delphi einsetzen,
<p>in der Vergangenheit waren immer wieder Diskussionen zu dem Thema. Darum
fasse ich noch mal zusammen und teile hier meinen aktuellen Stand mit.
<p>Unter bestimmten Bedingungen tritt auf Win9x Rechner das Problem auf,
daß die ToolBar oder das PageControl die von Delphi zugewiesenen
Grafiken der ImageList einfach nicht anzeigen. Besonders verheerend ist
dies natürlich bei der Toolbar, die abgesehen von den Hint's die Identifizierung
für den Benutzer ja nur über diese Images ermöglicht.
<p>Also Fehlerursache kamen immer wieder S3(Trio)-Chip's zur Sprache. Ebenso
wurde ein Ressourcen problem, bei Microsoft unter der ID Q182819
bekannt, zur Sprache gebracht. Microsoft bietet auch ein Tool zum Patchen
der Exe an, aber bei mir zum Beispiel, hat es einfach nicht gegriffen.
<p>Um irgendwelche Größenprobleme auszuschließen habe
ich letztendlich eine kleine Testanwendung geschrieben, mit einer Imagelist
mit einigen Grafiken, einer Toolbar und einem PageControl. Auch da trat
der Fehler auf. Wo dort jedoch fehlerträchtige 'large Ressources'
sein sollten, ist mir schleierhaft.
<p>Wir haben auf den betreffenden Rechnern auch schon die ComDlg32.dll
geupdatet. Tja, hätten wir auch bleiben lassen können. Wie gesagt,
nicht jeder mit Win9x, S3 Trio und alter ComDlg32.dll wird diesen Fehler
reproduzieren können. Anscheinend sind noch weitere Bedingungen für
diesen Fehler notwendig.
<p>Hinweis: Im allgemein sind die Fehler somit oft auf 'älteren'
Laptops reproduzierbar, da hier offensichtlich häufiger alle Bedingungen
für den Bug erfüllt sind. Ich habe Inprise/Borland das Problem
zwar geschildert -> no response.
<p>Achso, ob Delphi 5 oder Delphi 5 mit SP1 ist ebenso egal für diesen
Bug.
<p><b>Schlechte aber ERFOLGREICHE </b>Lösung:
<p>Vor der endgültigen Auslieferung der Exe exportiert man ALLE ImageList's
der betreffenden Anwendung. Dann lädt man diese Bitmap's in PAINTBRUSH
und speichern es unter Bitmap 16 Farben. Man löscht die Inhalte der
ImageList's in Delphi und lädt die frischen 4bit Bitmaps in die ImageList's.
OHNE zu speichern ERZEUGT man eine neue Exe-Datei der betreffenden Anwendung.
Sobald Ihr mit Delphi einmal das betreffende Form gespeichert habt, beginnt
der Spaß, zumindest ab dem Laden in die ImageList, für jede
Auslieferung wieder von vorn.
<p>Wie gesagt, die hier gezeigte Methode ist nicht grade edel, aber <b>WIR</b>
haben SEIT dieser Technik von unseren Beta-Testern keine einzige negative
Rückmeldung zu diesem Problem mehr, also es scheint zu funktionieren.
Die Tatsache, das dieser Fehler nicht in Anwendungen wie MS-Office auftritt
legt hier doch zumindest ein Delphi-Fehlverhalten nahe. Intern speichert
Delphi nämlich wohl die ImageList immer mit 32bit.
<p><b>Meine Frage</b>: hat jemand eine andere Lösung gefunden. Wenn ja, wir
haben bei uns noch einen alten Laptop, der es momentan als derartige Testplatform
tut. Ich würde alternative Lösungen gern da mal probieren.
<p>Danke, Mario
<p>in der Vergangenheit waren immer wieder Diskussionen zu dem Thema. Darum
fasse ich noch mal zusammen und teile hier meinen aktuellen Stand mit.
<p>Unter bestimmten Bedingungen tritt auf Win9x Rechner das Problem auf,
daß die ToolBar oder das PageControl die von Delphi zugewiesenen
Grafiken der ImageList einfach nicht anzeigen. Besonders verheerend ist
dies natürlich bei der Toolbar, die abgesehen von den Hint's die Identifizierung
für den Benutzer ja nur über diese Images ermöglicht.
<p>Also Fehlerursache kamen immer wieder S3(Trio)-Chip's zur Sprache. Ebenso
wurde ein Ressourcen problem, bei Microsoft unter der ID Q182819
bekannt, zur Sprache gebracht. Microsoft bietet auch ein Tool zum Patchen
der Exe an, aber bei mir zum Beispiel, hat es einfach nicht gegriffen.
<p>Um irgendwelche Größenprobleme auszuschließen habe
ich letztendlich eine kleine Testanwendung geschrieben, mit einer Imagelist
mit einigen Grafiken, einer Toolbar und einem PageControl. Auch da trat
der Fehler auf. Wo dort jedoch fehlerträchtige 'large Ressources'
sein sollten, ist mir schleierhaft.
<p>Wir haben auf den betreffenden Rechnern auch schon die ComDlg32.dll
geupdatet. Tja, hätten wir auch bleiben lassen können. Wie gesagt,
nicht jeder mit Win9x, S3 Trio und alter ComDlg32.dll wird diesen Fehler
reproduzieren können. Anscheinend sind noch weitere Bedingungen für
diesen Fehler notwendig.
<p>Hinweis: Im allgemein sind die Fehler somit oft auf 'älteren'
Laptops reproduzierbar, da hier offensichtlich häufiger alle Bedingungen
für den Bug erfüllt sind. Ich habe Inprise/Borland das Problem
zwar geschildert -> no response.
<p>Achso, ob Delphi 5 oder Delphi 5 mit SP1 ist ebenso egal für diesen
Bug.
<p><b>Schlechte aber ERFOLGREICHE </b>Lösung:
<p>Vor der endgültigen Auslieferung der Exe exportiert man ALLE ImageList's
der betreffenden Anwendung. Dann lädt man diese Bitmap's in PAINTBRUSH
und speichern es unter Bitmap 16 Farben. Man löscht die Inhalte der
ImageList's in Delphi und lädt die frischen 4bit Bitmaps in die ImageList's.
OHNE zu speichern ERZEUGT man eine neue Exe-Datei der betreffenden Anwendung.
Sobald Ihr mit Delphi einmal das betreffende Form gespeichert habt, beginnt
der Spaß, zumindest ab dem Laden in die ImageList, für jede
Auslieferung wieder von vorn.
<p>Wie gesagt, die hier gezeigte Methode ist nicht grade edel, aber <b>WIR</b>
haben SEIT dieser Technik von unseren Beta-Testern keine einzige negative
Rückmeldung zu diesem Problem mehr, also es scheint zu funktionieren.
Die Tatsache, das dieser Fehler nicht in Anwendungen wie MS-Office auftritt
legt hier doch zumindest ein Delphi-Fehlverhalten nahe. Intern speichert
Delphi nämlich wohl die ImageList immer mit 32bit.
<p><b>Meine Frage</b>: hat jemand eine andere Lösung gefunden. Wenn ja, wir
haben bei uns noch einen alten Laptop, der es momentan als derartige Testplatform
tut. Ich würde alternative Lösungen gern da mal probieren.
<p>Danke, Mario