Autor |
Beitrag |
motion
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: Mo 18.03.13 23:49
Eine alte Applikation von mir wurde bisher unter WinXP problemlos angewendet.
Unter Win7 und Win8 (Vista habe ich für Tests jetzt nicht im Zugriff) im Basis-Design keine Probleme; nur bei den Aero-Designs gibt es sporadische Anzeigefehler. Labels werden einfach nicht angezeigt.
OK
FEHLER (fehlende Labels)
Hat das irgendwas mit Manifesten oder so zu tun?
Schalte ich bei laufendem Programm die Windows Oberfläche zwischen Aero und Basis hin und her, so ändert sich die Anzeige nicht. Erst wenn das Programm beendet und neu gestartet wird, tritt der besagte Effekt auf.
Kennt jemand sowas und hat einen Tip zur Problemlösung zur Hand?
Applikation erstellt mit Delphi7 und TMS Komponenten (TXPMANIFEST vielleicht verantwortlich?)
Moderiert von Narses: Bilder als Anhang hochgeladen.
Einloggen, um Attachments anzusehen!
|
|
WasWeißDennIch
      
Beiträge: 653
Erhaltene Danke: 160
|
Verfasst: Di 19.03.13 10:26
|
|
motion 
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: Di 19.03.13 22:57
Bin ich nicht sicher.
Ich habe mal das TXPManifest aus der App rausgeworfen, brachte aber nix.
Etwas goggelei brachte das zum Vorschein:
jessicarbrown.com/bl...d-after-screenshots/
Sind wohl ähnliche Probleme wie bei mir. Nur keine richtige Lösung für mich schätze ich.
Ich muß momentan noch was anderes lösen, aber zum Wochenende werde ich mal weiter forschen ...
|
|
Andreas L.
      
Beiträge: 1703
Erhaltene Danke: 25
Windows Vista / Windows 10
Delphi 2009 Pro (JVCL, DragDrop, rmKlever, ICS, EmbeddedWB, DEC, Indy)
|
Verfasst: Mi 20.03.13 08:53
Den Fehler, das beim drücken der ALT-Taste u. a. Buttons verschwinden, konnte ich unter D7 mit VistaAltFix beheben.
Einloggen, um Attachments anzusehen!
|
|
motion 
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: Do 02.01.14 20:58
Ich muß das Problem noch mal wieder hochholen. Unter Vista/Win7 habe ich das Problem nicht lösen können und es erst mal durch das Abschalten von Aero verdrängen können.
Aber jetzt mit Win8.1 (win8 habe ich bzw. meine Kunden ausgelassen) beißt mich das wieder in den A*sch
Hat jemand noch eine Idee zur Ursache?
Ich habe noch etwas geforscht: Die betreffenden Label sind korrekt "visible:=True". Sind aber nicht zu sehen. Erst wenn ich die visible noch mal auf false und danach wieder auf true setze, sind sie sichtbar.
Ich habe jetzt erst mal alle betreffneden TLabel (war nur knapp eine Handvoll) durch TStaticText ersetzt. Damit scheint das aus der Welt.
Aber ich beobachte bei meinen Tests auch einige TRadioButton die nicht sichtbar sind. Aber das Verhalten ist momentan noch nicht reproduzierbar. Einmal Formular schließen und neu auf und sie werden angezeigt. Tritt wohl nur selten auf.
Sehr merkwürdig ...
|
|
jaenicke
      
Beiträge: 19314
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 02.01.14 22:36
Leider gibt es mit Delphi 7 noch diverse Probleme mit Vista und höher. Das liegt schlicht daran, dass es deutlich älter ist als Vista...
Deshalb würde ich es normalerweise nur für die Entwicklung für XP und niedriger empfehlen. Das heißt nicht, dass es gar nicht mit Vista und höher geht, aber empfehlen würde ich es nie dafür.
In deinem Fall frage ich mich allerdings ein wenig was dort Labels zu suchen haben. Das ist doch ein klassischer Fall für ein Grid wie TVirtualStringTree.
Nichtsdestotrotz löst das das Problem nicht überall, da du das Problem ja auch an anderen Stellen haben wirst. Was ich bei Delphi 7 beobachten konnte:
Schon eine TPaintBox oder ein OwnerDraw führt zu solchen Darstellungsfehlern.
Hättest du vielleicht ein kleines Demoprojekt, bei dem der Fehler auftritt?
|
|
motion 
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: Do 02.01.14 22:52
>Das heißt nicht, dass es gar nicht mit Vista und höher geht, aber empfehlen würde ich >es nie dafür.
Ja, das ist schon klar. Aber der Umstellungsaufwand auf z.B. XE5 (da taste ich mich gerade rein) ist üppig. Außerdem soviel Geld dann in Dritt-Komponenten zusätzlich anlegen ist heftig. Das sieht wirtschaftlich wohl zu dünn aus....
Aber ist taste mich schon mal langsam auf XE5 vor ... das dauert aber noch Monate bis das fertig ist.
Bisher siehe die Applikation unter Win81 ganz brauchbar aus. Zwei komische Sachen sind mir bisher noch aufgestoßen (da mache ich aber noch mal separate Threads auf, wenn ich die nicht gelöst kriege):
-gelegentliche Exceptions an Adresse 000000000
-beim Beenden des Programms bleibt es unter Win81 als "Hintergrundprozess" stehen und verbrät dauerhaft um die 25% CPU-Zeit bis ich das im Taskmanager beende.
Beides kann ich aber noch nicht reproduzieren.
Zurück zum Thema...
>>In deinem Fall frage ich mich allerdings ein wenig was dort Labels zu suchen haben. >>Das ist doch ein klassischer Fall für ein Grid wie TVirtualStringTree.
Dynamische Felder, Höhen, Buttons etc. ... habe ich vor Jahren gelöst als unterschiedliche Frames, die Dynamisch in einer Liste erzeugt werden.
Heute mit modernen Grid-Komponenten könnte man das wirklich besser realisieren.
>Was ich bei Delphi 7 beobachten konnte:
>Schon eine TPaintBox oder ein OwnerDraw führt zu solchen Darstellungsfehlern.
Ist mir bisher noch nicht untergekommen, verwende ich auch nicht. Aber könnte ja bei externen Komponenten vorkommen.... Ich werde mal drauf achten.
>Hättest du vielleicht ein kleines Demoprojekt, bei dem der Fehler auftritt?
Leider nicht; ich kriege den Fehler nicht auf einem einfachen Form reproduziert...
|
|
jaenicke
      
Beiträge: 19314
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Do 02.01.14 23:23
So hoch sollte der Aufwand einer Umstellung auf XE5 eigentlich gar nicht sein.
Aber das kommt natürlich auch auf die Größe des Projekts und die Qualität des Quelltexts an.
motion hat folgendes geschrieben : | Zwei komische Sachen sind mir bisher noch aufgestoßen (da mache ich aber noch mal separate Threads auf, wenn ich die nicht gelöst kriege):
-gelegentliche Exceptions an Adresse 000000000
-beim Beenden des Programms bleibt es unter Win81 als "Hintergrundprozess" stehen und verbrät dauerhaft um die 25% CPU-Zeit bis ich das im Taskmanager beende.
Beides kann ich aber noch nicht reproduzieren. |
Das hört sich nach Speicherproblemen an. Da sollte dir FastMM4 im FullDebugMode helfen.
|
|
motion 
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: Fr 03.01.14 01:20
FastMM habe ich schon drin, aber den FullDebugMode muß ich zu der Untersuchung noch mal aktivieren. Wahrscheinlich dieses Wochenende ...
|
|
jaenicke
      
Beiträge: 19314
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Fr 03.01.14 01:24
Wenn du Speicher überschreibst, weil du z.B. schon freigegebenen Speicher verwendest, kann das übrigens neben vielen anderen Problemen auch zu den Grafikproblemen führen. Deine Fehlerbeschreibung deutet darauf zwar nicht unbedingt hin, zeigt aber, dass in der Richtung etwas nicht stimmt.
Um den FullDebugMode zu aktivieren musst du nur den entsprechenden Schalter in der Include-Datei von FastMM umstellen.
Solltest du z.B. auf ein freigegebenes Objekt zugreifen, kommt dann eine entsprechende Meldung. Die Include-Datei mit den Optionen, die ich immer verwende, liegt im Anhang.
Einloggen, um Attachments anzusehen!
|
|
Hochhaus
      
Beiträge: 662
Erhaltene Danke: 8
Windows 7
Delphi XE2
|
Verfasst: Fr 03.01.14 07:47
Wie wäre es, wenn Du das Projekt jemandem gibst, zu dem Du Vertrauen hast - und der es Dir dann unter Delphi XE2 oder höher kompiliert ?
Hochhaus
|
|
motion 
      
Beiträge: 295
XP, Linux
D7 Prof
|
Verfasst: So 05.01.14 13:50
Outsourcen ginge natürlich genauso wie wenn ich es selbst mache. Aber der Aufwand (Zeit & Geld) ist halt sehr hoch.
Ich werde erst mal schauen wie die Applikation unter Win81 läuft. Bisher sieht es ganz gut aus. Und die beiden geschilderten Bugs werde ich auch noch finden 
|
|
jaenicke
      
Beiträge: 19314
Erhaltene Danke: 1747
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: So 05.01.14 16:03
motion hat folgendes geschrieben : | Aber der Aufwand (Zeit & Geld) ist halt sehr hoch. |
Das ist einer der Gründe weshalb wir auf Fremdkomponenten soweit als möglich verzichten.
Die Umstellung unserer Hauptanwendungen von D5 auf XE lief seinerzeit bei uns zwar nicht 100%ig glatt (ein paar wenige Bugs, hauptsächlich bei den diversen Hardwareansteuerungen, wurden ein paar Monate später noch gefunden), dauerte aber nur wenige Tage. Und insgesamt hielten sich die dadurch verursachten Bugs sehr in Grenzen, während die neuen Features sehr viel möglich gemacht haben. Alle verwendeten Fremdkomponenten konnten wir, da diese selbstverständlich mit Quelltext gekauft wurden, erst einmal selbst aktualisieren.
Die Modernisierung des Quelltextes insgesamt kam dann hinterher, aber da war die Anwendung schon lauffähig.
Bis jetzt habe ich noch kein Projekt getroffen, bei dem die Umstellung wirklich ewig gedauert hat, es sei denn Fremdkomponenten waren dafür verantwortlich.
|
|