Halli hallo,

ich habe eine ganz blöde Frage,
und hoffe, das ich dafür nicht gehenkt werde.

In meinem Code, der Daten aus einer Paradox-Datenbank holen und in eine MSSQL-Datenbank schreiben soll,
ist folgendes Kostrukt (verkürzt) zu finden:



FimportPossible ist eine boolsche Variable, die im private-Bereich meiner Import-Klasse deklariert wurde, und die ich intern an
anderen Stellen (natürlich noch innerhalb der Klasse) auswerte, wenn beim Import etwas schiefgelaufen ist. Natürlich hätte ich auch nochmal ein raise durchführen können,
aber das ist ein anderes Thema.

Das Problem ist vielmehr: FimportPossible wird nie false gesetzt! Wenn ich absichtlich eine Exception erzeuge und im except-
Abschnitt im Debugger lande, so führt er alles brav aus, aber in der Zeile FimportPossible := false muss ich komischerweise sogar zweimal
F8 drücken um die Zeile zu durchlaufen- und selbst dann ist immer noch FimportPossible True. Ich hatte es in die Liste
überwachter Ausdrücke übernommen.

Was ist denn da los? Momentan kann ich mir nicht erklären, wie so etwas simples nicht funktionieren kann.

Moin!

Wenn es nicht einen bestimmten Grund gibt, die Ausnahmeverarbeitung so zu machen, dann lass das on weg:

Weiterhin: schalte die Optimierung aus, sonst kann eine Variable auch z.B. in einem Register landen, was man nicht debuggen kann (jedenfalls nicht mit den überwachten Ausdrücken).

cu
Narses

Grund: Leider sind nicht alle Exceptions von Exception abgeleitet. Wenn man alle erwischen will, muss man daher on E: TObject schreiben und schauen was für einen Typ man hat um es weiter auszuwerten.

Das on E:Exception habe ich rausgenommen. Die Optimierung lasse ich sowieso immer aus, solange der Code noch nicht fertig und fehlerfrei ist.

Trotzdem immer noch dasselbe.. auch wenn ich den Mauszeige direkt auf FimportedPossible halte, sehe ich, das es sich nicht auf false ändert.
Und ich sehe ja auch, das der Debugger die Zeile durchläuft.

Ach ja, wir nutzen hier noch immer Delphi 7.

Moin!

mczero098 hat folgendes geschrieben :

Ach ja, wir nutzen hier noch immer Delphi 7.

Was mich betrifft, ist das auch OK, spricht ja nix dagegen (auch wenn jaenicke das anders sehen wird ). Ich nutze auch D7pro.

mczero098 hat folgendes geschrieben :

Trotzdem immer noch dasselbe.. auch wenn ich den Mauszeige direkt auf FimportedPossible halte, sehe ich, das es sich nicht auf false ändert. Und ich sehe ja auch, das der Debugger die Zeile durchläuft.

Bei so "Zicken" des Debuggers mache ich dann immer ein ShowMessage() und lasse das nochmal laufen. Wird dann auch immer noch TRUE ausgegeben?

cu
Narses

Ja das stimmt, es spricht im Prinzip nichts gegen Delphi 7, ich mag den Charme von Delphi 7 trotz seines Alters
Abgesehen vom grauenhaften WebModule Debugging über den IIS, wenn ich mich mal wieder an eines unserer ISAPI-Module setze...
Aber das trifft in diesem Fall nicht zu, es ist (soll werden...) eine Desktopanwendung.

Zurück zum Problem. Ich habe es mit ShowMessage probiert.
Folgendes ist passiert:

Zeile FimportPossible := false -> Überwachter Ausdruck springt tatsächlich auf false
Dann Zeile ShowMessage(BoolToStr(FimportPossible,true)) -> Auch hier, false!
Dann erreicht er das End des Exception Blocks. Hier wird plötzlich der überwachte Ausdruck True!!

Dann verlasse ich die Methode und lande im übergeordneten Code. Auch hier, ist FimportedPossible plötzlich True!

Nebenläufigkeit mit mehreren Threads wende ich übrigens auch nicht an. Ich glaube, das sollte ich beim Zugriff auf Paradox-Datenbanken
auch sein lassen (anderes Thema )

Moin!

Namenskollision, Scope-Probleme?

cu
Narses

Scope: Deklaration von FimportPossible findet im Private-Abschnitt der Klassendeklaration statt.
Nach Namenskollisionen habe ich auch gesucht. Da FimportPossible nicht allzu oft verwendet wird, konnte ich schnell feststellen, das
das hier nicht der Fall ist.

Ich weiß echt nicht weiter. Aber es ärgert mich, bisher konnte ich Fehler immer in meinem Code ausmachen, und nicht als
Delphi-Problem identifizieren(außer wie oben schon erwähnt WebModule-Debugging ) - deswegen vermute ich den Fehler immer noch in meinem Code.
Aber wo suchen?? Es bleibt ja nichts... oder doch?

Ist FImportPossible nur einfach eine Variable, oder wird diese Variable z.B. durch eine property gesetzt. Beim zweiten Fall könnte vielleicht irgendeine Prozedur ja ebenfalls FImportPossible setzen und dann hast Du Deine Kollision. Ansonsten wüsste ich jetzt auch nicht, was da falsch sein könnte.

Allerdings könntest Du ja einfach mal testen, was passiert, wenn die drei Zeilen außerhalb von Try .. except .. end liegen, somit also immer ausgeführt werden (Dann natürlich ohne on E:...). Vielleicht wird ja FImportPossible trotzdem nicht auf FALSE gesetzt.

mczero098 hat folgendes geschrieben :

Zeile FimportPossible := false -> Überwachter Ausdruck springt tatsächlich auf false Dann Zeile ShowMessage(BoolToStr(FimportPossible,true)) -> Auch hier, false! Dann erreicht er das End des Exception Blocks. Hier wird plötzlich der überwachte Ausdruck True!!

In einer aktuellen Delphiversion wäre es einfach:
Datenhaltepunkt setzen und schauen ob und wenn ja wo das Feld verändert wird. So viel zu dem Thema.

Egal, geht bei dir ja nicht. Was du versuchen kannst:
Gib IntToStr(Integer(Self)) mit dem Wert aus. Und setze das ShowMessage nach das end des Exceptionblocks zusätzlich, wenn du meinst, dass es sich da ändert. (Statt Self ggf. die Variable auf das Objekt, wenn du außerhalb bist.) So siehst du, ob du immer im selben Objekt bist. Zudem solltest du einen Haltepunkt auf den Destruktor setzen um sicherzustellen, dass das Objekt nicht schon freigegeben wird.

Außerdem kannst du aus dem Feld eine property machen und das Feld umbenennen. Dabei benutze einen Setter und setze darin einen Haltepunkt, dann merkst du, wenn das gesetzt wird.

Tja was soll ich sagen..
ich habe das System aus einem anderem Grund neu gestartet, und siehe das, das Problem
hat sich komplett verflüchtigt (bisher)! Leider ist das trotzdem bisschen unbefriedigend.
Ich kann mich mit nicht erklärbaren Fehlern nie wirklich anfreunden.

Aber die IntToStr(Integer(Self)) - Methode ist eine Klasse Idee, die ich an anderen Stellen noch prima
gebrauchen kann!

Danke Leute!

jaenicke hat folgendes geschrieben :

In einer aktuellen Delphiversion wäre es einfach: Datenhaltepunkt setzen und schauen ob und wenn ja wo das Feld verändert wird. So viel zu dem Thema. Egal, geht bei dir ja nicht.

Doch.

Kontextmenü auf den Ausdruck: "Ausdruck am Cursor anzeigen", dann in der "Liste überwachter Ausdrücke" Kontextmenü "Bei Änderung anhalten".

Da wurde nur die Bezeichnung geändert.

In welcher Delphiversion geht das? Bei D7 PE gibt es das offenbar nicht, siehe Anhang, ebenso wenig finde ich es bei Turbo Delphi, Delphi 2007 oder Lazarus.

Siehst du die doppelten Splitter in deinem Menü über Show Column Headers? Genau da ist die Option

Soweit ich weiß, ist das bei allen Versionen die "Zur Exception-Adresse gehen" im Suchen-Menü haben. Das wäre dann ab "Professional".

Scheint aber nicht sehr bekannt zu sein, auf der Suche nach der Feature Matrix hab ich mehrere Forenbeiträge gefunden, in denen behauptet wird sowas existiere nicht. Vielleicht kam das auch erst mit einem Update?