Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Kurz gesagt:
- in initialization kann man lokale Variablen initialisieren oder andere Funktionen ausführen, welche bei Programmstart ausgeführt werden müssen - in finalization genau das Gegenteil, also lokale Variablen freigeben (z.B. für Pointer und Objekte) und abschließende Prozeduren ausführen Zitat:
Begin-End kann man eigentlich überall im Code einfügen: (diese kann man im Prinzip auch nehmen, um Codeblöcke optisch zu trennen)
Delphi-Quellcode:
procedure Test;
begin begin begin WriteLn('123'); end; WriteLn('456'); end; begin WriteLn('789'); end; end;
Delphi-Quellcode:
...
initialization WriteLn('start'); finalization begin WriteLn('ende'); end; end. Zitat:
Die Prozeduren kommen in implementation und diese kannst du dann in initialization oder finalization aufrufen. Die Abschnitte innerhalb von, bzw. hinter/unter initialization, finalization und begin (in der DPR) sind wie die Funktionsrümpfe zu verwenden, also so also würden sie schon zwischen einem begin-end liegen. |
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Hallo,
Zitat:
Gruß Hawkeye |
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Delphi-Quellcode:
Da erklärt der mir leider, dass tsringlist nen undefinierter Bezeichner ist...hmmm...was hab ich da nun falsch gemacht bzw. woran hab ich nicht gedacht?
unit unit2
var Spielliste : tstringlist; .............. Danke schon mal *zugeb* |
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Hi,
das Problem mit TStringList ist aber eine andere Frage!!! Zum ursprünglichen Problem, bei der Verwendung von Com-Objekten ist die Nutzung von initialization und finalization recht Praktisch:
Delphi-Quellcode:
Ansonsten, wenn Fragen dazu sind, bitte in der Hilfe nachlesen, dort ist es eigentlich gut erklärt.
initialization
CoInitialize(nil); finalization CoUninitialize; Schönen Abend noch. |
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Das CoInitialize kann da aber schon zu spät sein, weil z.B. ComServ schon vorher eingebunden wird und da wird das bereits gemacht. Außerdem ist der Aufruf von CoUnitialize problematisch, wenn irgendjemand noch COM benutzt. Wenn soetwas der Fall ist, dann geht CoUnitialize in eine Schleife und wartet solange, bis COM fertig ist.
Ich würde empfehlen, Co(Un)itialize nur im Hauptprogramm (und Threadfunktionen) zu verwenden, damit man 100% Kontrolle besitzt. So kann man noch noch CoUnitialize alle Interfaces schließen und muss nicht suchen, in welche Unit das gemacht werden soll. Außerdem kann die Benutzung in externen Bibliotheken noch viel größere Probleme bereiten. Oh man, das musste ich alles erleben, als ich JwsclComSecurity für JWSCL geschrieben habe. Im Endeffekt gilt für Initialization und Finalization, dass je lokaler die Auswirkungen sind, desto geeigneter ist der Platz dafür. Wenn also andere Units (und womöglich Threads) abhängig sind von solch einer Variablen, dann muss man schon sehr gut planen, damit das alles funktioniert. |
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Zitat:
|
Re: Sinn & Funktion Initialisierungs-/Finalisierungsteil
Die Finalisierungen werden in umgekehrter Reihenfolge abgearbeiter, wie ihre Units initialisiert wurden.
Und Units, welche im Interface eingebunden wurden, werden immer davor initialisiert und demnach auch erst hinterher finalisiert (also im Vergleich zu der Unit, in welcher die entsprechende Unit eingebunden wurde) !!! eine im Implementationsteil eingebundene Unit kann davor oder danach initialisiert werden. Also ist es schon möglich, daß man mit Sicherheit eine verhältnismäßige Reihenfolge voraussetzen kann, wenn man gewisse Punkte beachtet. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:10 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