Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi TLabel auf TPanel = Zugriffsverletzung beim Start (https://www.delphipraxis.net/164146-tlabel-auf-tpanel-%3D-zugriffsverletzung-beim-start.html)

nuclearping 30. Okt 2011 22:42

TLabel auf TPanel = Zugriffsverletzung beim Start
 
Hallo!

Ich habe hier in meinem aktuellen, schon gut gewachsenem, (D2009) Projekt, ein echt seltsames Verhalten.

Ich habe einen TFrame, auf dem unter anderem ein TPanel liegt, in welchem bereits drei TLabels sind. Dort will ich nun ein weiteres TLabel unterbringen. Wenn ich das jedoch mache und dann die Software starte, erhalte ich eine Zugriffsverletzung und Delphi springt dann entweder an eine Stelle in der Classes.pas (zB Funktion NotifyGlobalLoading) oder in der System.pas (zB Funktion _LStrAddRef) oder manchmal bekomme ich nur das CPU-Fenster, je nachdem, ob das TLabel schon "verarbeitet" ist (Platzierung und Name zB) oder nicht.

Entferne ich das TLabel, läuft das Projekt wieder. Platziere ich in das besagte TPanel etwas anderes (TButton, TEdit, TMemo, ...), läuft das Projekt auch. Und wenn ich ein TJvLabel von der JVCL dareinsetze, läuft es ebenso.

Das einzige, was dieses Problem verursacht, ist ein TLabel oder ein TLabeledEdit.

Ich habe mir jetzt - wie schon gesagt - erstmal mit einem TJvLabel geholfen. Aber was dieses Verhalten soll, verstehe ich nicht.

Jemand eine Idee?

himitsu 30. Okt 2011 23:20

AW: TLabel auf TPanel = Zugriffsverletzung beim Start
 
Hatte vor einer Weile auch ein Problem, wo es beim Start unerklärlich krachte.

Leider sagt die Halteposition und der Stacktrace nicht immer wirklich etwas aus.
Bei uns ist es ein größeres Projekt, aus vielen BPLs und DLLs
und jenachdem welches Projekt in der Projektgruppe grade aktiv ist,, ändert sich dramatisch die Halteposition.

z.B. landete ich fast immer in der DPR, bei CreateForm, aber als dann das richtige Projekt aktiv und die passende PAS geladen war, zeigte er mir die richtige Stelle :wall:


Nja, am Ende hab ich mich Stück für Stück in die angezeigte Fehlerstelle reingearbeitet, mit ganz viel F7, F8 und wandernten Haltepunkten.
Erstmal in großen schritten rein, sich jeweils die letzte Stelle merkend, Haltepunkte gesetzt, bis es wieder knallt und da dann alles von Vorne, nur eben an der letzten Stelle dann einen kleineren Schritt ......... bis ich nach Stunden endlich die Stelle hatte. :wall:
Eventuell dann auch mal die VCL-Debug-DCUs aktivieren, wenn man irgendwann nicht weiterkommt und es bei F7 sofort knallt.

Sowas wie Eurekalog kann auch hilfreich sein ... ist aber kein allesheilendes Wundermittel.



Bei soeinem "zuverlässigen" Fehler ist wenigstens die Change groß, den ausfindig zu machen.







So, da dieses Problem ja wohl sonst keiner Nachvollziehen kann und du vermutlich deine Quellcodes nicht rausrückst, wirst du wohl selber erstmal auf Suche gehn müssen.
Kannst dich aber gerne schonmal an den Emba-Support wenden, wenn du wirklich der Meinung bist, es müsse ein Bug sein und könne kein selbstverschuldetes Problem sein.

Furtbichler 31. Okt 2011 06:29

AW: TLabel auf TPanel = Zugriffsverletzung beim Start
 
Was passiert, wenn Du die PAS+DFM speicherst und dann wieder lädst?

Bummi 31. Okt 2011 14:47

AW: TLabel auf TPanel = Zugriffsverletzung beim Start
 
klingt als ob irgendwo über die Komponenten gelaufen wird und wenn Components[i] is TCustomLabel etwas ausgeführt wird .....

nuclearping 31. Okt 2011 15:48

AW: TLabel auf TPanel = Zugriffsverletzung beim Start
 
Zitat:

Zitat von himitsu (Beitrag 1133623)
[...]

z.B. landete ich fast immer in der DPR, bei CreateForm, aber als dann das richtige Projekt aktiv und die passende PAS geladen war, zeigte er mir die richtige Stelle :wall:

[...] Eventuell dann auch mal die VCL-Debug-DCUs aktivieren, wenn man irgendwann nicht weiterkommt und es bei F7 sofort knallt.

Ja, Anfangs bin ich auch immer in der DPR, genau an der gleichen Stelle, gelandet. Dann habe ich die Debug DCUs mit reinkompiliert und seither springt er immer zwischen Classes.pas und System.pas hin und her.

Steppen mit F7 und F8 habe ich auch schon probiert. Das komische ist, dass wenn ich im besagten Frame in Create am Anfang einen Breakpoint setze und durchsteppe, knallt es nicht. Wenn er das Ende des Constructors erreicht, springt er dann wieder in die Message-Behandlungsroutinen und loopt dadurch, bis mir der Finger vom F8 drücken weh tut. Drücke ich dann F9, braucht er noch ein paar Sekunden und dann kommt die ZV.

Zitat:

Zitat von himitsu (Beitrag 1133623)
So, da dieses Problem ja wohl sonst keiner Nachvollziehen kann und du vermutlich deine Quellcodes nicht rausrückst, wirst du wohl selber erstmal auf Suche gehn müssen.
Kannst dich aber gerne schonmal an den Emba-Support wenden, wenn du wirklich der Meinung bist, es müsse ein Bug sein und könne kein selbstverschuldetes Problem sein.

Das Projekt ist (für diesen Fall) leider kommerziell und die Quellcodes des Projekts sind ziemlich umfangreich, greifen auf eigene Komponenten und Hardware-APIs zurück, die Software braucht auch eine Hardware, um zu laufen, etc.
Also selbst wenn ich die Codes zur Verfügung stelle, wird die niemand ohne weiteres zum laufen bekommen. :mrgreen:

Die Notlösung mit dem TJvLabel passt erstmal. Optisch gibts da ja keinen Unterschied, ist nur inkonsistent vom Design her.

Ich werde mir demnächst auch mal eine aktuelle Delphi Version zulegen, bzw. das erstmal bei einem Kollegen mit seinem Delphi XE kompilieren und schauen, ob es da genauso noch auftritt. Ich vermute aber fast nicht. D2009 ist doch schon recht betagt.

Zitat:

Zitat von Furtbichler (Beitrag 1133628)
Was passiert, wenn Du die PAS+DFM speicherst und dann wieder lädst?

Bringt nichts, hatte Delphi deswegen schon X mal neugestartet, Computer neugestartet, Kompatibilitätsmodus probiert, ...


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:25 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz