Dateiausgabe über Auswahl-Objekt TSaveDialog

[h.g.mueller]

Ich versuche zur Zeit meinunter Delphi6 lauffähiges Programm auf Delphi8 umzustellen.
Bei TSaveDialog.Execute
kommt die Meldung
Ungültiges Thread-Modell (StathreadAttribute erforderlich)

Bislang habe ich die Threads nicht explizit verwaltet.
Hat einer ne Idee was es sein kann?

[Andreas Kosch]

Hallo,

>Hat einer ne Idee was es sein kann?

in der Projektdatei (*.dpr) muss das <b>STAThread</b>-Attribut hinzugefügt werden:
<pre>
[STAThread]
<b>begin</b>
Application.Run(TWinForm.Create);
<b>end</b>.
</pre&gt

[h.g.mueller]

Danke!
Das Fenster von OPENDialog geht jetzt auf, dafür erscheint beim Verlassen des Programms eine neue Fehlermeldung auf:
"Projekt project1.exe traf auf die unbehandelte Exeption-Klasse System.NullReferenceException. Prozess angehalten.
Mit Einzelne Anweisung oder Start fortsetzen"

Was könnte hier die Ursache sein

[Andreas Kosch]

Hallo,

&gt;Was könnte hier die Ursache sein?

das ist eine lange Geschichte. Die Kurzfassung lautet so: Um einen Bug zu beseitigen, hat Borland einige Tage vor der Auslieferung der RTM-Version einen grundlegenden Umbau in der System-Unit sowie im MSIL-Generator des Delphi-Compilers vorgenommen, der als unerwünschte Nebenwirkung dazu führt, dass das bisherige Verhalten der früheren Delphi-Versionen sowie der <i>Delphi.NET Preview</i> im Beich des <b>Finalization</b>-Abschnitts <b>nicht</b> mehr mit dem Verhalten von Delphi 8 übereinstimmt. Mit dem Beispielprojekt <i>DemoWakeup.dpr</i> aus meinem Crashkurs-Buch kann dies nachvollzogen werden:

Verhalten der Delphi.NET Preview (Inhalt der Protokolldatei):
<pre>
OssiSoft.DelphiNET.UnitA
initialization
OssiSoft.DelphiNET.UnitB
initialization
TraceDemo: Begin
TraceDemo: End
OssiSoft.DelphiNET.UnitB
finalization
OssiSoft.DelphiNET.UnitA
finalization
</pre>
Verhalten von Delphi 8 (Inhalt der Protokolldatei):
<pre>
OssiSoft.DelphiNET.UnitA
initialization
OssiSoft.DelphiNET.UnitB
initialization
TraceDemo: Begin
TraceDemo: End
</pre>
Die Fehlermeldung <i>System.NullReferenceException</i> erscheint immer dann, wenn das Programm über einen Verweis auf ein Objekt zugreift, das noch nicht als Instanz erzeugt wurde oder das zum Zeitpunkt des Zugriffs bereits zerstört wurde.

Lange Rede kurzer Sinn: Jede Projekt-Unit bzw. jede Komponten-Unit, die einen <b>Finalization</b>-Block nutzt, sollte überprüft werden. Soweit möglich, sollte der Finalization-Block durch etwas anderes ersetzt werden

[h.g.mueller]

In meinen Programmen habe ich keinen Finalization-Block gefunden, zumindest nichts was so auch dort bezeichnet ist.
Wie kann ich den Fehler beheben?

Ist bei Borland ein Patch geplant oder schon ladbar der die jetzt in Delphi vorhandenen neuen Fehler behebt?
Eine graphische Entwicklungsoberfläche in die man in die Source eingreifen muß um die Verwaltung von graphisch plazierten Elemente sicherzustellen ist meiner Meinung nach noch unausgegoren.
Ich denke wirklich daran wieder auf Delphi 6 zurückzugehen bis die Probleme behoben sind

[Andreas Kosch]

Hallo,

&gt;..habe ich keinen Finalization-Block gefunden..

trifft dies auch für alle direkt (und indirekt) eingebundenen Units (VCL-Komponenten) zu?

&gt;Wie kann ich den Fehler beheben?

Es ist (meiner Meinung nach) nur ein Ausnahmefällen sinnvoll, eine bestehende VCL-Anwendung mit Delphi 8 weiterzuentwickeln. Die wenigsten Probleme treten bei Delphi 8 auf, wenn man ein neues Projekt für die FCL beginnt.

&gt;Ist bei Borland ein Patch geplant ....

Nach den Äußerungen in den Newsgroups sowie in den einschlägigen Blogs gehe ich davon aus, dass erst Delphi 9 grundlegende Änderungen bringen wird

[h.g.mueller]

Vielen Dank für Ihre Hilfe!

Ich bin dann mit meinem kleinen Programm wieder auf Version 6 zurück gegangen.
Bei einer nicht kompartiblen Version 8 mit Hilfetexte die bei weitem nicht so informativ sind wie ich sie unter 6 gewohnt bin, lasse ich beim Versionswechsel lieber den Kollegen der Vortritt.

Es ist mir einfach nicht verständlich daß Delphi zum Beispiel den Dialog (TSaveDialog) über das Auswahlmenue anbietet, aber dann selber nicht ohne manuelle Eingriffe verwalten kann.
Aus das ein simples "Close" ein Problem werden kann läßt noch mehr befürchten.

Da gibt es nur ein Urteil: Unausgegorene Version.

Bei dem Rat neu anzufangen stellt sich mir die Frage was Entwickler mit bestehenden großen Programmen machen sollen. Aus meiner jetzigen Sicht wäre es ratsam sich das Geld fürs Update zu sparen. (sorry

[Andreas Kosch]

Hallo,

&gt;Bei einer nicht kompartiblen ...

Delphi 8 ist <b>nicht</b> der Nachfolger von Delphi 7, sondern eine völlig neue Produktlinie. Nicht ohne Grund liegt für Win32-Anwendungen eine Delphi 7-CDROM mit in der Verkaufpackung von Delphi 8. Erst Delphi 9 soll sowohl der Nachfolger von Delphi 7 (Win32) als auch der Nachfolger von Delphi 8 (.NET) sein.

&gt;..mit bestehenden großen Programmen machen sollen.

Die grundlegende Frage ist doch, <b>warum</b> eine bestehende Anwendung auf .NET umgestellt werden soll. In meinen Augen macht das nur dann Sinn, wenn die Anwendung in weiten Teilen von den neuen Fähigkeiten des .NET Frameworks einen Nutzen hat. Aber um die Vorteile von .NET tatsächlich Nutzen zu können, muss man auch die Architektur der Altanwendung entsprechend anpassen. Dies bedeutet, dass jede Migration nach .NET mit umfassenden Umbauarbeiten verbunden ist.

Für die meisten "alten" Anwendungen (mit Ausnahme aller Web-Anwendungen) ist es besser, bei Bedarf nur bestimmte Teile nach .NET auszulagern. Da Delphi 8 den unmangaged Export beherrscht, kann Delphi 5/6/7 direkt eine mit Delphi 8 kompilierte DLL aufrufen (ohne den COM Interop-Umweg). Somit kann die Altanwendung mit neuen .NET-Fähigkeiten nachgerüstet werden.

Die Aussage "Umstellung nach .NET durch einfache Neukompilation des alten VCL-Projekts" ist ein reiner Marketing-Spruch, der bei realen Anwendungen mit der Wirklichkeit nichts zu tun hat

[h.g.mueller]

Danke für die Klarstellungen

[h.g.mueller]

Danke für die Klarstellungen!
Ich denke das war die grundlegende Info die mir fehlte