Was kompiliert Delphi 10.3.3 da???

[harfes]

Ich habe eine procedure in einem Programm, die unter 10.2 völlig problemlos läuft (es wird beim Klick auf einen Button aus einem DBgrid ein DBKey ausgelesen und diesem Eintrag im Grid dann eine andere Farbe gegeben und das in der zugehörigen DB (Firebird mit IBDAC) gesichert):

if (DBPlanner1.Items.Selected.DBKey<>'') then
begin
laufendenr:=DBPlanner1.Items.Selected.DBKey;
with DM1.DataModule1.IBPlanungSQL do
begin
Close;
SQL.Clear;
SQL.Add('UPDATE PLANUNG SET ');
SQL.Add('ITEMCOLOR = :ITEMCOLOR, ERLEDIGT = :ERLEDIGT ');
SQL.Add('WHERE ITEMKEY = :OLD_ITEMKEY');
Params[0].Value:=7;
Params[1].Value:='T';
Params[2].Value:=laufendenr;
ExecQuery;
Close;
end;
DM1.DataModule1.IBTransaction1.CommitRetaining;
DBPlanner1.Refresh;
end
else
begin
ShowMessage('Bitte einen Termin markieren!');
end;

Wenn ich mein Programm nun unter 10.3.3 kompiliere (ohne Fehler), starte (völlig problemlos) und diesen Button betätige, wird das Programm geschlosssen! Die Datenänderung wird aber vorher noch in der DB gesichert! Ich habe auch schon das DBPlanner1.Refresh ausgeschaltet - es schliesst sich trotzdem.

Die genutzten Komponenten sind die gleichen wie in 10.2 und aktuell (IBDAC und TMS DBAdvGrid). Es gibt keine Fehlermeldung...wie komme ich da an das Problem heran???


Hartmut

[zeras]

Nimm doch bitte mal die With Anweisung weg und schreibe alle Objekte komplett aus.
Möglicherweise bezieht sich das

Delphi-Quellcode:

Close;

auf dein Formular und nicht auf deine DB Verbindung.

Und benutze auch bitte die Delphi Tags. Danke.

[Daniel]

Du kannst einen Breakpoint setzen und dann die paar Zeilen durchlaufen und so schauen, welche Zeile für das Programmende verantwortlich ist.
Und ja, das "Close" ist ein heißer Kandidat.

[harfes]

And the winner is: CLOSE !!!

ABER: warum funktioniert das in 10.2 und warum schliesst sich das Programm nicht schon beim ersten Close? Noch was: wenn ich hinter DM1.DataModule1.IBPlanungSQL den Punkt setze, um die Möglichkeiten anzuzeigen, dann gibt es gar kein Close!!! Warum gibt das keinen Compilerfehler???

Sorry, aber nachdem 10.3.1 und 10.3.2 schon nicht zum produktiven Arbeiten geeignet waren, sehe ich aktuell auch bei 10.3.3 noch keine Veranlassung zum Jubeln! Ja, es hat sich vieles verbessert - aber irgendwie macht mir so ein (nicht angezeigter) Fehler doch Sorgen...

Hartmut

[Daniel]

Fehler ist hier vielleicht der falsche Begriff. Bei einer der von Dir genutzten Klassen sich sich offenbar eine Methode ".Close" in der Sichtbarkeit verschoben. Bei Dir äußert sich das eben sehr drastisch - ist aber exakt das Paradebeispiel, mit dem vor der Verwendung von "with" gewarnt wird.
Wenn Du das Ganze ohne "with" voll ausprogrammierst, wird Dein Code tadellos laufen.

[harfes]

Ja, da hast Du recht: durch das ausprogrammieren habe ich den "Fehler" ja auch gefunden bzw eure Anmerkung verifiziert. Im nachhinein ist es ja auch merkwürdig, dass der Compiler von 10.2 auch nicht meckert - das close aber anscheinend stillschweigend ignoriert, so dass der Code funktioniert.

Ich werde morgen mal ein grösseres Projekt mit der 10.3.3 testen...

Hartmut

[Uwe Raabe]

Was ist denn DM1.DataModule1.IBPlanungSQL für ein Typ?

[jaenicke]

Sei froh, dass der Fehler so offen sichtbar aufgefallen ist. Mit with handelt man sich oft Fehler ein, die man nur schwer überhaupt eingrenzen und finden kann, wenn sie bei einem Nutzer auffallen.

Außerdem ist es einer der Hauptgründe für Probleme bei Updates auf eine neue Delphiversion.

Und debuggen lässt sich solch ein Code ja auch kaum, weil der Debugger mit with nicht arbeiten kann.

Dazu kommt noch die schlechte Lesbarkeit, weil du nie siehst was wozu gehört (in diesem Fall Close). Und weil du auch kicht siehst, ob deine gewünschte Zuordnung mit der des Compilers übereinstimmt...

Wer bei uns Code mit with eincheckt, wird virtuell gesteinigt. ��

Zitat:

Zitat von harfes (Beitrag 1451934)

Im nachhinein ist es ja auch merkwürdig, dass der Compiler von 10.2 auch nicht meckert - das close aber anscheinend stillschweigend ignoriert, so dass der Code funktioniert.

In 10.2 gab es in dem Objekt im with offenbar eine entsprechende Methode, die vermutlich die Verbindung geschlossen hat.
Das ist ja genau das Tückische, wenn man mit with nicht explizit schreibt wozu etwas gehören soll. Dann muss der Compiler nach seinen Regeln dies ermitteln.

[Uwe Raabe]

Zitat:

Zitat von harfes (Beitrag 1451934)

Im nachhinein ist es ja auch merkwürdig, dass der Compiler von 10.2 auch nicht meckert - das close aber anscheinend stillschweigend ignoriert, so dass der Code funktioniert.

Hast du eventuell bei 10.3.3 eine neue Version der Komponente installiert? Vielleicht war vorher ein Close vorhanden.

Zitat:

Zitat von harfes (Beitrag 1451931)

ABER: warum funktioniert das in 10.2 und warum schliesst sich das Programm nicht schon beim ersten Close?

Weil das Close nur eine CM_RELEASE Message in die Queue stellt.

[zeras]

Zitat:

Zitat von harfes (Beitrag 1451931)

Sorry, aber nachdem 10.3.1 und 10.3.2 schon nicht zum produktiven Arbeiten geeignet waren, sehe ich aktuell auch bei 10.3.3 noch keine Veranlassung zum Jubeln! Ja, es hat sich vieles verbessert - aber irgendwie macht mir so ein (nicht angezeigter) Fehler doch Sorgen...

Hartmut

Ist denn 10.3.1 und 10.3.2 so schlecht?
Ich habe ein größeres Projekt immer wieder auf die aktuelle Version hochgezogen und konnte keine Probleme feststellen.
Natürlich könnte alles viel besser sein, aber wer hat schon ein Projekt, was man nicht verbessern könnte?:lol:

[harfes]

@Uwe Raabe: es handelt sich um die TIBCSQL-Komponente aus dem IBDAC-Paket von Devart. Und die eingesetzen Komponenten sind die selben Versionen, die ich auch in 10.2 verwendet.

@jaenicke: ok, Steinigung wird angenommen! Aber: zu meiner "Verteidigung" muss ich sagen, dass ich with schon seit vielen Jahren problemlos nutze (auch in grösseren Projekten) und bisher nie Probleme damit hatte. Aber nach den Erklärungen hier, werde ich das wohl ändern...wenn der Compiler/Debugger nicht wirklich was mit dem Code im with-Bereich anfangen kann, dann hatte ich bisher wohl immer Glück.

@zeras: die gemeldeten Fehler für die 10.3.1 und 10.3.2 hier im Forum sprechen für sich - zumal es bei einigen funktioniert, bei anderen nicht. Das würde ich als unzuverlässig einstufen. Diese Erfahrungen musste auch ich machen, aber die 10.3.3 macht bisher einen guten Eindruck. Des weiteren habe ich alle Delphi-Versionen jeweils in einer eigenen Maschine, so dass ich nur manchmal ein Projekt "hochziehen" muss. Neue Projekte fange ich aber immer in der aktuellsten Version an - sofern diese stabil ist...

Hartmut

[DieDolly]

Ich habe schon seit der ersten kostenlosen Starter-Version seltsame Fehler die es bis heute gibt.
Nicht oft aber immer wieder mal wenn ich ein etwas größeres Projekt kompiliere, wird der Vorgang abgebrochen und mit einem Fehler an einer Zeile quittiert, wo es gar keinen Fehler gibt. Bis vor ein paar Updates war dieser Fehler immer am Ende einer Unit in einer Zeile, wo gar nichts steht. Fehler noch immer da, aber an einer anderen Stelle wo es trotzdem keinen Fehler gibt.

[Bernhard Geyer]

Zitat:

Zitat von DieDolly (Beitrag 1451960)

Nicht oft aber immer wieder mal wenn ich ein etwas größeres Projekt kompiliere, wird der Vorgang abgebrochen und mit einem Fehler an einer Zeile quittiert, wo es gar keinen Fehler gibt. Bis vor ein paar Updates war dieser Fehler immer am Ende einer Unit in einer Zeile, wo gar nichts steht. Fehler noch immer da, aber an einer anderen Stelle wo es trotzdem keinen Fehler gibt.

Das könnte aber auch am Virenscanner liegen, der einfach nicht mehr Geschwindigkeit der Compilierung hinterherkommt und zufällig irgendwelche Units blockiert an denen der Compiler/IDE einfach kein Problem erwartet und deshalb auch nicht mit einer vernünftigen Fehlermeldung die eigentliche Ursache beschreibt.

Am besten z.B. die dcu-Dateien vom Scan ausnehmen.

[p80286]

Zitat:

Zitat von harfes (Beitrag 1451957)

Aber: zu meiner "Verteidigung" muss ich sagen, dass ich with schon seit vielen Jahren problemlos nutze (auch in grösseren Projekten) und bisher nie Probleme damit hatte.

Du Unglücklicher. Ich war zu TP-Zeiten begeisteter "with"-Nutzer, bis irgendwann einmal die Daten keinen Sinn mehr ergaben. Beim debuggen hat mir ein Vertreter der C-Fraktion über die Schulter geschaut und gemurmelt "woher soll der Compiler wissen was Du meinst?"
Auch ich versuchte es mit "aber bisher.....". Antwort:"aber jetzt nicht!"Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler
hat keinen Ermessensspielraum, und das ist's was zählt.

Gruß
K-H

[jaenicke]

Ich bekomme beim einfachen Kompilieren nach einer Änderung im Interface einer Unit auch ab und zu mal einen internen Fehler oder Typ xyz nicht gefunden (der in der Unit deklariert ist). Das lässt sich dann nur mit einem Neuerstellen lösen.

Da das nicht reproduzierbar ist, lässt sich das aber eben kaum melden...

Solche Probleme hatten wir aber auch schon bei XE (dort auch ohne Änderung). Das ist seitdem schon deutlich seltener, tritt aber auch bis mind. 10.3.2 auf.

Zitat:

Zitat von harfes (Beitrag 1451957)

wenn der Compiler/Debugger nicht wirklich was mit dem Code im with-Bereich anfangen kann, dann hatte ich bisher wohl immer Glück

Das kannst du ganz einfach testen. Versuche einfach mal per Mouseover den Hint zu der Property SQL zu bekommen. Oder versuche mit Strg + F7 z.B. Params[0].Value aus deinem Code auszuwerten.

Du wirst sehen, dass du da zuerst den Inhalt deines with davor schreiben musst. Und das bremst halt beim Debuggen enorm... zumal du manchmal gar nicht genau siehst, ob du das durch den with-Ausdruck ergänzen musst oder nicht...
Und wenn du dort z.B. Width auswertest und es das außen und im with-Ausdruck gibt, wertet der Debugger von außen aus, z.B auf das Formular bezogen, weil er das woth nicht kennt...

[jaenicke]

Zitat:

Zitat von p80286 (Beitrag 1451965)

Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler
hat keinen Ermessensspielraum, und das ist's was zählt.

Man sollte das ja auch in Variablen zwischenparken. ;-)

[p80286]

Eine weitere Möglichkeit!
Hauptsache kein

Delphi-Quellcode:

with

!

Gruß
K-H

[Bernhard Geyer]

Eine Syntaxerweiterung wie bei VB (ok, ich werde jetzt gesteinigt) würde schon helfen.
Was mit "with" behandelt werden soll muss mit "." anfangen.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1451967)

Man sollte das ja auch in Variablen zwischenparken. ;-)

Wobei der MMX Code Explorer beim Eliminieren der with-Bereiche ja diesbezüglich etwas Hilfe anbietet...

[DenkDirNix]

Zitat:

Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler hat keinen Ermessensspielraum, und das ist's was zählt.

Einen "Ermessensspielraum" hat der Compiler hier natürlich nicht. Die Reihenfolge der Versuche zum Auflösen der Variablen im with ist durchaus eindeutig vorgegeben.
Das gleiche Problem haben wir ja auch, wenn eingebundene Units identische Bezeichner exportieren. Und dieses Problem ist sogar noch größer, weil kein verdächtiges "with" in der Nähe steht.

Ich halte "with", auf private, lokal deklarierte Strukturen angewendet, für vollkommen okay. Im Debugger muss man dann halt die with-Variable komplett anzeigen und sich ggf durchhangeln. Der Vorteil des with ist gar nicht mal die entfallende Tipparbeit, sondern die Übersichtlichkeit-mangels-Masse des geschriebenen Codes.
:evil:

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1451971)

Eine Syntaxerweiterung wie bei VB (ok, ich werde jetzt gesteinigt) würde schon helfen.
Was mit "with" behandelt werden soll muss mit "." anfangen.

Die Inlinevariablendeklaration ist dafür ja absolut ausreichend.
(Wobei ich selbst sie aus Übersichtlichkeitsgründen nicht verwende.)

[Lemmy]

Zitat:

Zitat von jaenicke (Beitrag 1451967)

Zitat:

Zitat von p80286 (Beitrag 1451965)

Natürlich sind Myvalues.Myrecs.Correlation1.recval78.Runtime nicht tippfreundlich oder Übersichtsfördernd aber der Compiler
hat keinen Ermessensspielraum, und das ist's was zählt.

Man sollte das ja auch in Variablen zwischenparken. ;-)

Nein. Wer so was braucht hat ein Designproblem! Das hat nix, aber so was von gar nix mit OOP zu tun...

[Uwe Raabe]

Zitat:

Zitat von Lemmy (Beitrag 1451981)

Wer so was braucht hat ein Designproblem!

Das Designproblem kann ja aber auch im Code liegen, den man nicht selbst unter Kontrolle hat.

[Harry Stahl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1451974)

Zitat:

Zitat von jaenicke (Beitrag 1451967)

Man sollte das ja auch in Variablen zwischenparken. ;-)

Wobei der MMX Code Explorer beim Eliminieren der with-Bereiche ja diesbezüglich etwas Hilfe anbietet...

Und inwiefern bietet der MMX Code Explorer dabei Hilfe an?

Hatte das Tool mal vor längerer Zeit kurz installiert, war dann aber von der Vielfalt etwas erschlagen und es fehlte mir ein gutes Tutorial, das mir einen Überblick verschafft hätte.

Aber meine "With-Verbrechen" aus älteren Code würde ich auch gerne los werden, wenn der MMX-Explorer da eine gute Unterstützung anbietet (sollte also schon mehr sein, als nach "With" zu suchen), würde ich es evtl. noch mal versuchen...

[Uwe Raabe]

Ist in der Hilfe unter Members view refactorings - Pascal refactorings - Convert with statement beschrieben. Vielleicht muss ich noch mehr Videos machen...

[Harry Stahl]

Ok danke, das sieht ja so aus, dass einem hier einiges an Tipparbeit erspart werden könnte. Werde ich also morgen Abend mal installieren und testen.

Ja gerne, Videos und bitte auch mit Sprache, irgendwelche Textblasen finde ich nicht so hilfreich.
Es wäre so eine allgemeine Übersicht schön und insbesondere was das Tool so kann, was man mit Delphi nicht kann...

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1451989)

Ok danke, das sieht ja so aus, dass einem hier einiges an Tipparbeit erspart werden könnte.

Noch hilfreicher sollte es mit der Implementierung des LSP Servers in 10.4 werden können. Das werde ich mir dann auch anschauen...

Zitat:

Zitat von Harry Stahl (Beitrag 1451989)

Ja gerne, Videos und bitte auch mit Sprache, irgendwelche Textblasen finde ich nicht so hilfreich.

Das hat aber den Vorteil, dass man es auch ohne Kopfhörer oder Lautsprecher nutzen kann. Es gibt immer Vor- und Nachteile.
Wobei ich jetzt nicht sagen möchte, dass es hier unbedingt so oder so sein sollte. ;-)

[Rolf Frei]

Wieso diskutiert ihr jetzt so über das Pro/Contra von "with"? Wenn sein Object in der "with" Anweisung eine Methode Close hat, muss diese aufgerufen werden und das ist auch klar so definiert. Soll die Form.Close aufgrufen werden muss Self.Close geschrieben werden. Wenn das nicht der Fall ist, haben wir hier eindeutig einen üblen Bug in 10.3.3 und dieser sollte dringends gemeldet werden!

Ob WITH gut oder böse ist spielt hier garkeine Rolle.

EDIT
Habe eben mal die Onlinedoku zu TIBCSQL angeschaut und nach der gibt es kein Open/Close in dieser Klasse. Die ist auch nicht etwa von TDataset abgeleitet, sondern von TComponent. Ein SQL wird da mit Execute ausgeführt. Somit ist es klar was da passiert. Dass der Code aber vorher so problemlos gelaufen sein soll, bezweifle ich mal gewaltig.

https://www.devart.com/ibdac/docs/de...ac.tibcsql.htm

[MichaelT]

Prinzipiell würde Close der Query der Vorzug gewährt.

Mal abseits des with.


1) TIBCSQL Ganz sicher?
Close und ExecQuery?

Überbleibsel einer Migration oder?

2) Glaube nicht, dass die EMB da allzuviel rumpfrimmelt.

Zitat:

Zitat von harfes (Beitrag 1451957)

@Uwe Raabe: es handelt sich um die TIBCSQL-Komponente aus dem IBDAC-Paket von Devart. Und die eingesetzen Komponenten sind die selben Versionen, die ich auch in 10.2 verwendet.

@jaenicke: ok, Steinigung wird angenommen! Aber: zu meiner "Verteidigung" muss ich sagen, dass ich with schon seit vielen Jahren problemlos nutze (auch in grösseren Projekten) und bisher nie Probleme damit hatte.

Hartmut

[MichaelT]

Vermutlich sind die Methoden aus Gründen der Kompatibilität zu TIB Components da.

Das Close könnte mit einer mit einer TIBCQuery (nicht TIBCSQL) über TDataset gekommen sein, aber ExecQuery nicht mehr.

Eigentlich ist die Nomenklatur eher Execute und ExecSQL ...

Ob die Methoden etwas taten und woher sie kamen ist wie du sagst ein anderes Thema.

Zitat:

Zitat von Rolf Frei (Beitrag 1452044)

EDIT
Habe eben mal die Onlinedoku zu TIBCSQL angeschaut und nach der gibt es kein Close in dieser Klasse. Die ist auch nicht etwa von TDataset abgeleitet, sondern von TComponent. Somit ist es klar was da passiert. Dass der Code aber vorher so problemlos gelaufen sein soll, bezweifle ich mal gewaltig.

[sakura]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1451962)

Zitat:

Zitat von DieDolly (Beitrag 1451960)

Nicht oft aber immer wieder mal wenn ich ein etwas größeres Projekt kompiliere, wird der Vorgang abgebrochen und mit einem Fehler an einer Zeile quittiert...

Das könnte aber auch am Virenscanner liegen, ...

Könnte, glaube ich aber nicht. Dieses Phänomen haben wir hier auch, bei größeren Projekten geht im Compiler irgendwo etwas schief. Wieso ich Virenscanner ausschließe? Einfach: es passiert immer an den gleichen Stellen, wenn ich bestimmte Änderungen an anderen Stellen vornehme. Immer...

...:cat:...

P.S.: Außer Windows-Tools keine weiteren Virenscanner in der VM.
P.P.S.: Es passiert auf jedem Dev-PC, immer.

[harfes]

@Rolf Frei + MichaelT: Ja, es kommt aus einer Migration von FIBPlus nach IBDAC...allerdings ist dieser Code schon seit XE7 dort und funktioniert bis einschliesslich 10.2 problemlos. Warum, frage ich mich jetzt allerdings selber! Aber solange der Compiler und vor allem der Kunde nicht meckert, fällt es halt nicht auf (und die dahintersteckende Funktion wird täglich so um die 30-50mal aufgerufen - das würde bei Nichtfunktion natürlich schnell auffallen).

Auch der 10.3.3-Compiler meckert ja nicht, interpretiert aber anscheinend den Code intern jetzt anders und das führt beim Ausführen des Programms zu besagtem "Fehler". Damit sind wir wieder beim with...und: irgendetwas muss sich am/im Compiler ja geändert haben, sonst würde jetzt ja nicht dieses "Problem" aufgetaucht sein. Ich habe für mich jedenfalls den Schluss gezogen, dass ich with in Zukunft nicht mehr verwenden werde - auch wenn ich es persönlich übersichtlicher finde...
Des weiteren habe ich die Komponente TIBCSQL mal gegen eine TIBCQuery getauscht und es beim with belassen (es heisst dann aber ExecSQL und nicht mehr ExecQuery) -> damit funktioniert auch die procedure mit with einwandfrei.

Hartmut

[Uwe Raabe]

Zitat:

Zitat von harfes (Beitrag 1452080)

Auch der 10.3.3-Compiler meckert ja nicht, interpretiert aber anscheinend den Code intern jetzt anders

Ich bin ziemlich sicher, daß das nicht der Fall ist. Wenn das in 10.2.3 Tokyo mit dem Close innerhalb des with noch nicht zu einem Schließen des Forms geführt hat, dann entweder weil die with-Klasse dort noch ein Close kannte oder ein hier nicht sichtbarer Code das verhindert hat (z.B. innerhalb OnCloseQuery).

[Rolf Frei]

Ich vermute mal, dass du da in XE7 irgendwie die alten FIBPlus Komponenten genutzt hast (falscher Suchpfad, der noch auf FIBPLus zeigte), ohne dir dessen bewusst zu sein. Jetzt in 10.3.3 hast du vermutlich andere Pfade oder die alten zum FIBPlus garnicht erst mehr in der Suchliste. Das wäre für mich die einzige Erklärung. Das hätte so auch in XE7 nicht funktioniert, wenn da wirklich die selben Komponenten gelinkt wurden.

[MichaelT]

Hallo,

FIB plus war ein Maß unbestritten.

Yep. Ich kann mich nurmehr düster an Diskussion in grauer Vorzeit erinnern aus den Konsequenz der Einbau dieser Kompatibiltätsfunktionen war. Der Usercode wird nicht migriert. In dem Eck holt man noch keine Speed ohne tatsächlich umzubauen.

Das muss sich auch mal rentieren. Die Speed einer Anwendung hochzutreiben heißt noch lange nicht, dass wenn alle gegen einen Server arbeiten davon profitieren. Deswegen ist die Devart mit Standardeinstellungen so mal im Mittel ganz gut.

Ich habe 10.3.3 noch nicht installiert und IBDAC nicht in Verwendung und damit keine Sourcen. Es stellt sich die Frage ob nicht über Interfaces Leerimplementierungen resp. ergänzende 'hereinvererbt werden' damit alles gleich bleibt und andererseits in den Komponenten Abläufe automatisch werden angestoßen. Devart hat sich in dem Eck sehr viel angetan.

Ich denke mich düster zu erinneren, dass Devart den Close vom Windows abfangen, ihre Arbeit erledigen und dann selbst absetzen. (Sicher bin ich mir nach Jahren nicht mehr, ob der Zusammenhang dort war). So etwas in die Richtung ist es vermutlich. Hätte es folgerichtig in der Vergangenheit auch schon sein müssen. Das verwundert mich persönlich genauso.

Zitat:

Zitat von harfes (Beitrag 1452080)

@Rolf Frei + MichaelT: Ja, es kommt aus einer Migration von FIBPlus nach IBDAC...allerdings ist dieser Code schon seit XE7 dort und funktioniert bis einschliesslich 10.2 problemlos. Warum, frage ich mich jetzt allerdings selber! Aber solange der Compiler und vor allem der Kunde nicht meckert, fällt es halt nicht auf (und die dahintersteckende Funktion wird täglich so um die 30-50mal aufgerufen - das würde bei Nichtfunktion natürlich schnell auffallen).

Auch der 10.3.3-Compiler meckert ja nicht, interpretiert aber anscheinend den Code intern jetzt anders und das führt beim Ausführen des Programms zu besagtem "Fehler". Damit sind wir wieder beim with...und: irgendetwas muss sich am/im Compiler ja geändert haben, sonst würde jetzt ja nicht dieses "Problem" aufgetaucht sein. Ich habe für mich jedenfalls den Schluss gezogen, dass ich with in Zukunft nicht mehr verwenden werde - auch wenn ich es persönlich übersichtlicher finde...
Des weiteren habe ich die Komponente TIBCSQL mal gegen eine TIBCQuery getauscht und es beim with belassen (es heisst dann aber ExecSQL und nicht mehr ExecQuery) -> damit funktioniert auch die procedure mit with einwandfrei.

Hartmut

[harfes]

Ok, ich habe gerade gesehen, dass die von mir verwendete, aktuellste Version 7.0.1 der IBDAC noch nicht für 10.3.3 freigegeben ist (laufen tut sie jedenfalls). Ich bin gespannt, ob der alte with-Code mit dem Close auch dann wieder laufen wird...lt. Devart soll die neue Version nächste Woche kommen.

Und nein, ich werde den Code nicht so lassen, auch wenn es laufen sollte! Jetzt suche ich gerade, ob es von den "Migrationsresten" noch mehr gibt...:shock:

Hartmut

[Harry Stahl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1451987)

Ist in der Hilfe unter Members view refactorings - Pascal refactorings - Convert with statement beschrieben. Vielleicht muss ich noch mehr Videos machen...

OK, habe das Tool jetzt mal installiert (mein letzter Versuch war 2015, habe ich dabei festgestellt).

Zur "Convert-With"-Funktion: Ja, das hilft tatsächlich die Umstellung zu machen, insofern :thumb:

Die Hilfe musste ich mir allerdings aus dem Programmverzeichnis raus suchen, eine Programmgruppe wurde nicht angelegt (auch im Delphi-Hilfe-Menü kein Eintrag).

Mir sind noch eine Reihe von weiteren Dingen aufgefallen, wenn Du interessiert bist, sende ich Dir diese gerne per privater Nachricht zu.

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1452099)

Mir sind noch eine Reihe von weiteren Dingen aufgefallen, wenn Du interessiert bist, sende ich Dir diese gerne per privater Nachricht zu.

Dann doch bitte als einzelne Mails an [e-mail] - dann wird gleich jeweils ein eigener Case dafür angelegt.

[Harry Stahl]

OK, schon passiert...

[Fritzew]

Ich arbeite zur Zeit viel mit Remobjects Elements (früher mal Delphi Prism)

Die Erweiterungen die Remobjects da gemacht hat gefällt mir wirklich gut:
aus der Dokumentation: https://docs.elementscompiler.com/Ox...atements/With/
Es lohnt sich mal in die Dokumentation zu schauen .... Remobjects hat meiner Meinung nach die Sprache super aufgewertet....

Zitat:

The with can be used to temporarily introduce new members in the scope. It supports multiple with items seperated by a comma. The main benefit of with over using a regular local var declaration is that with more explicitly limits the scope of the new variables to the statement or block of statements it applies to. The do keyword can be followed by a single statement or a begin/end block grouping multiple statements.

Delphi-Quellcode:

with fb := CalculateFooBar do begin
  writeLn(fb);
end;

// fb is not available here anymore.