Erste Erfahrungen mit D2006

[hanspeter]

Hallo, D2006 habe ich seit Anfang Dezember im Haus und bin jetzt erst dazugekommen gründlich zu testen.
Ich habe versucht ein größeres produktives Projekt umzustellen und durchaus gemischte Erfahrungen gemacht.
Die Übernahme alter Componenten war eine Odysee. Bei vielen Componentenherstellern ist die Entwicklung bei D5 oder D7 stehen geblieben.
Ibobjects (4.0) hatte ich ursprünglich nicht zum Laufen bekommen.
Nach dem Update auf 4.5 und einen weiteren direkt zugesandten Update ging es dann.
Manche Bibliotheken verriegeln sich gegenseitig.
Also Componente A in Bibliothek A benötigt Bibliothek C und bindet diese implizit ein.
Benötigt jetzt Componente B in Bibliothek B auch die Bibliothek C, dann kann die Bibliothek anschließend nicht geladen werden.
(B benötigt C, die auch in A eingebunden ist.)
Fastreport liegt z.B. bereits für D2006 vor. Will ich hier eine Vorlage in der dfm editieren, dann kommt ein "abstrakter Fehler".
Etwa alle 2 bis 3 Stunden stürzt bei mir die IDE (vor allen beim Debug) ab.
Stoppe ich auf einen Haltepunkt und betätige dann F9 geht die CPU Belastung auf 100% hoch und ich kann D2006 nur noch über den
Taskmanager abschießen.
(Heute bereits das Dritte oder vierte mal.)
Ich hatte auch schon Fehler wie "nicht genügend Speicherplatz für diese Operation" (2 Gbyte Hauptspeicher).
Danach kam immer beim Beenden von D2006 eine Speicherschutzverletzung in der rtl100.
Irgendwann war diese Meldung weg.
Anfangs habe ich mich über die vielen Warnungen gewundert, dann habe ich gemerkt, das Vererbungen case sensitive sind.
Also Destructor destroy; override; erzeugt eine Warnung, da Destructor geschrieben werden muß.
Die Hilfe hat sich verbessert, aber auch wenn ich nur mit der W32 Personality arbeite und verwende die Suchfunktion, dann kommen immer erst alle .NET Bezüge.
Die Codevervollständigung - Template ist , wenn man von D7 kommt, teilweise lästig und ich habe sie erstmal abgeschaltet.
(Jede if Anweisung hat erst mal einen Syntaxfehler und ich muss das automatisch eingefügte then entfernen).
Bei der Übernahme der Quellen des alten Projektes (1,2 Mio Quellzeilen) war anfangs mehrfach eine dfm-Datei nicht mehr zu öffnen.
Ich habe dann die betroffene Quelle aus meinem D7 Verzeichnis neu kopiert, dann ging es wieder.
Dabei auch eine eigenartige Beobachtung. Auch wenn die Quelle in der IDE geschlossen ist, dann scheint D2006 diese in einem Cache vorzuhalten.
Quelle in der IDE geschlossen. Im Explorer die Datei kopiert und in der IDE wieder geöffnet, es ist die alte Datei da.
Für solche Vorgänge mußte ich D2006 schließen und nach dem Kopieren erneut öffnen.

Vieles sicher Gewöhnungssache aber das wichtigste Problem, die Absturzfreudigkeit beim Debuggen, gibt es da schon einen Ratschlag oder Hinweis?

Mit Gruß

Peter

[jbg]

Zitat:

Zitat von hanspeter

Jede if Anweisung hat erst mal einen Syntaxfehler und ich muss das automatisch eingefügte then entfernen

Hast du andere Live-Templates als andere?

Ich schreibe "if<Leertaste>" und es steht da "if [True] then". Wo ist denn da der Syntaxfehler?

[Hansa]

Zitat:

dann habe ich gemerkt, das Vererbungen case sensitive sind

Kann das jemand bestätigen ? :shock: Wozu soll denn das gut sein ? Ich habe allerdings bei dem ganzen Bericht eher die dumpfe Vermutung, daß die IDE (noch) nicht richtig eingstellt ist. 8)

[jbg]

Zitat:

Zitat von Hansa

Kann das jemand bestätigen ?

Das ist seit Delphi 8 schon so, wenn da auch nur für .NET. Aber ab D2005 wurde das auch für Win32 eingeführt. Und ich muss sagen, dass bei meinen Codes (und das sind nicht gerade wenig) keine einzige Meldung dieser Art auftrat. Bei der JVCL gab es ein oder zwei, die aber gleich behoben waren.
STRG+Leertaste in der class-Deklaration nimmt einfach so viel Schreibarbeit ab und ist auch noch case-sensitive.

Zitat:

:shock:

Es schockt mich mehr, dass viele die Wörter querfeldein schreiben. Hier mal groß, da mal klein, dort mal gemischt. Manchmal bin ich nicht weit davon entfernt, mich hinzusetzen und ein Programmm zu schreiben, dass die Schreibweise, die bei der Deklaration benutzt wurde, auf den gesamten Code anzuwenden. Aber aus Zeitgründen wird das wahrscheinlich nie was werden und ich bin weiterhin schockiert.

Zitat:

Wozu soll denn das gut sein ?

Damit man sich mal an eine Schreibweise hält.

Zitat:

Ich habe allerdings bei dem ganzen Bericht eher die dumpfe Vermutung, daß die IDE (noch) nicht richtig eingstellt ist. 8)

Wie kommst du auf die IDE? Die Warnungen kommen vom Compiler nicht von der IDE.

[LarsMiddendorf]

Bedeutet dass, dass TTest = class(system.object) nicht funktioniert und ab jetzt TTest = class(System.Object) heißen muß?

[jbg]

Zitat:

Zitat von LarsMiddendorf

Bedeutet dass, dass TTest = class(system.object) nicht funktioniert und ab jetzt TTest = class(System.Object) heißen muß?

Abgesehen davon, dass man in .NET die Bezeichner so schreiben sollte, wie sie deklariert wurden, sollte das kein Problem sein. Was der Compiler anprangert ist folgendes:

Delphi-Quellcode:

TMyCtrl = class(TCustomControl)
public
  destructor destroy; override;
end;

Weil in TObject der Konstruktor mit einem großen "D" deklariert wurde.

[Hansa]

Zitat:

Zitat von jbg

Das ist seit Delphi 8 schon so...Wie kommst du auf die IDE? Die Warnungen kommen vom Compiler nicht von der IDE.

D8 ? :shock: Ja damit kann man sowieso nichts machen. Und das ist auch der Grund, daß D2005 nicht bestellt wird ! Und bei D2006 siehts ähnlich aus. Soll ruhig mal einer von Borland lesen. 8) Wenn in D2006 sogar Warnungen wegen solchem Firlefanz kommen, dann behindert das die Lokalisierung von eventuellen WinApi-Überbleibseln. Wenn man "tEst" stat "Test" für einen Identifier schreibt, dann soll das, zumindest in einer Nicht-Unix Umgebung egal sein. Nichtsdestrotrotz wird das natürlich korrigiert.

Und Compiler oder IDE, das ist völlig egal. Ob ich jetzt von Hand /$?? in die Kommandozeile schreibe, oder ein Häkchen irgendwo in der IDE setze ist völlig egal ! Noch nie was von "project".CFG gehört ? Oder ist das auch abgeschafft ?:mrgreen: Ich gehe allerdings davon aus, daß für solcherlei Warnungen ein Compilerschalter zum unterdrücken existiert. Und eben ein Häkchen in der IDE. :mrgreen:

[mikhal]

Ich habe mir in den letzten Tagen Delphi 2006 angeschaut. Obwohl ich heute den ganzen Tag in der IDE mit Delphi für Win 32 gearbeitet habe und dabei einiges getestet und mit F8 durchgestept habe, kann ich den bechriebenen Absturz nicht nachvollziehen. Sehr wohl kann ich die Beschreibung der Abhängigkeiten von Bibliotheken nachvollziehen. Meine Versuche, eine angepaßte RX-Lib zu installieren scheiterte mehrfach, warum es zum schluß dann doch funktionierte - keine Ahnung...

Das Problem mit der Schreibweise halte ich selbst auch nicht für problematisch, da ich es gewohnt bin, meine Quelltexte nach Möglichkeit Case-Sensitiv zu schreiben. Ist ein Überbleibsel aus meiner V/C++-Zeit (lang ist's her).

Im großen und Ganzen bin ich angenehm überrascht, da ich mit mehr Problemen gerechnet hatte. Mein größten Probleme werden aber die noch nicht verfügbaren Fremdkomponenten sein, die ich für die Anpassung bestehender Projekte unbedingt noch benötige (z.B. ODAC von CRLab, okay Beta-Release ist draussen), und daß ich mich jetzt doch mit den Rave-Reports auseinadersetzen muß, da die QuickReports wohl endgültig zum alten Eisen gepackt wurden (und mein Arbeitgeber zwar freundlicherweise ein Upgrade von Delphi finanzierte, aber beim Report-Modul dann streikte :???: ).

Grüße
Mikhal

[sakura]

Zitat:

Zitat von hanspeter

Bei vielen Componentenherstellern ist die Entwicklung bei D5 oder D7 stehen geblieben. [...] Manche Bibliotheken verriegeln sich gegenseitig.

Beides eher Probleme der Hersteller als von Delphi :zwinker:

Zitat:

Zitat von hanspeter

Stoppe ich auf einen Haltepunkt und betätige dann F9 geht die CPU Belastung auf 100% hoch und ich kann D2006 nur noch über den

Ich habe es auch schon erlebt - zwei mal, aber leider nie ein nachvollziehbares Beispiel erstellen können. :?

Zitat:

Zitat von hanspeter

Ich hatte auch schon Fehler wie "nicht genügend Speicherplatz für diese Operation" (2 Gbyte Hauptspeicher).

:shock: Den habe ich schon lange nicht mehr gesehen.

Zitat:

Zitat von hanspeter

Anfangs habe ich mich über die vielen Warnungen gewundert, dann habe ich gemerkt, das Vererbungen case sensitive sind. Also Destructor destroy; override; erzeugt eine Warnung, da Destructor geschrieben werden muß.

Interessant. Vorallem weil er in .NET nicht vorkommt :gruebel: Müsste man mal rausbekommen, was der Sinn da ist. Evtl. das Zusammenrücken vom C++ und dem Delphi-Compiler. In Zukunft sollen die Kompilate ja untereinander nutzbar sein und dann wird Groß- und Kleinschreibung wichtig.

Zitat:

Zitat von hanspeter

(Jede if Anweisung hat erst mal einen Syntaxfehler und ich muss das automatisch eingefügte then entfernen).

Ein Beispiel bitte. Wie oben schon geschrieben wird if TRUE then eingefügt, da ist eigentlich kein Syntaxfehler.

Zitat:

Zitat von hanspeter

Quelle in der IDE geschlossen. Im Explorer die Datei kopiert und in der IDE wieder geöffnet, es ist die alte Datei da. Für solche Vorgänge mußte ich D2006 schließen und nach dem Kopieren erneut öffnen.

Interessant, poste das bitte mal in die Bugsparte, damit das nicht verloren geht, oder besser gleich nach BORL QC.

...:cat:...

[jbg]

Zitat:

Zitat von mikhal

Ich habe mir in den letzten Tagen Delphi 2006 angeschaut. Obwohl ich heute den ganzen Tag in der IDE mit Delphi für Win 32 gearbeitet habe und dabei einiges getestet und mit F8 durchgestept habe, kann ich den bechriebenen Absturz nicht nachvollziehen.

Delphi 2006 stürzt da nicht ab, sondern ist sehr lange beschäftigt. Das Problem gibt es schon länger und tritt hauptsächlich bei größeren Projekten auf. Delphi prüft beim ersten F8 die Kompilat-Abhängigkeiten (CoreIDE::GetShouldBuild()). Und das kann schon mal beim ersten Mal länger dauern. Ein Arbeitskollege hat mich schon gefragt, ob ich da was dagegen tun kann. (deshalb weiß ich dass es in GetShouldBuild passiert). Da ich aber nicht genau weiß, wann diese Funktion außer bei F7/F8 noch aufgerufen wird, habe ich bis jetzt noch nichts unternommen. Für den BCB 5/6 habe ich das aber bereits eingebaut, da ich dort mit meinem bcc32pch ja sowieso den gesamten IDE Compiler ersetze.

Zitat:

Sehr wohl kann ich die Beschreibung der Abhängigkeiten von Bibliotheken nachvollziehen. Meine Versuche, eine angepaßte RX-Lib zu installieren scheiterte mehrfach, warum es zum schluß dann doch funktionierte - keine Ahnung...

Das kann an mehreren Sachen liegen. Angefangen über BPL Verzeichnis nicht in PATH-Umgebungsvariable, über fehlen der Pfade im Bibliothekspfad hin zu Compiler- und Komponentenunterschiede.

Zitat:

Das Problem mit der Schreibweise halte ich selbst auch nicht für problematisch, da ich es gewohnt bin, meine Quelltexte nach Möglichkeit Case-Sensitiv zu schreiben. Ist ein Überbleibsel aus meiner V/C++-Zeit (lang ist's her).

Sogar zu meinen TurboBASIC Zeiten habe ich schon case-sensitive programmiert und da kannte ich C bzw. C++ nur vom Hörensagen.

Zitat:

Im großen und Ganzen bin ich angenehm überrascht, da ich mit mehr Problemen gerechnet hatte.

Das einzige was etwas störend wirkt sind die ganzen neuen deprecated Funktionen. In der JVCL treten diese Meldung nun vermehrt auf. Aber da die JVCL Hinweis- und Warnungfrei sein soll, werden diese bald der Vergangenheit angehören.

Zitat:

Mein größten Probleme werden aber die noch nicht verfügbaren Fremdkomponenten sein, die ich für die Anpassung bestehender Projekte unbedingt noch benötige (z.B. ODAC von CRLab, okay Beta-Release ist draussen), und daß ich mich jetzt doch mit den Rave-Reports auseinadersetzen muß, da die QuickReports wohl endgültig zum alten Eisen gepackt wurden (und mein Arbeitgeber zwar freundlicherweise ein Upgrade von Delphi finanzierte, aber beim Report-Modul dann streikte :???: ).

Da liebe ich mir doch Komponenten mit Quellcode.