AfterConstruction in TObject

[Helmut Schumacher]

<pre> Hallo,

ist AfterConstruction von TObject noch
Bestantteil des Constructors vom Object?

Oder wird diese Procedure erst nach Ablauf
des Constructors aufgerufen?
Ich möchte in einem TThread in AfterConstruction CoInitialize aufrufen. Der Aufruf bringt zwar kein Fehler, aber wenn ich in Execute ein Comobjekt aufrufe, erhalte ich die Fehlermeldung: "CoInitialize wurde nicht
aufgerufen".

Helmut</pre>

[Robert Marquardt]

Ich bin nicht sicher, aber ich glaube nur Execute selber laeuft im Thread. Also sollte das CoInitialize als erstes im Execute stehen. Die COM-Objekte sollten erst danach ebenfalls im Execute erstellt werden, damit sie auch im Thread-Kontext stehen. Das Create des Threads ist definitiv im Hauptthread

[Hagen Reddmann]

Robert hat recht, dein Aufruf sollte so aussehen:

<pre>

procedure TMyThread.Execute;
begin
try
CoInitialize(nil);
try
while not Terminated do
begin
end;
finally
CoUninitialize;
end;
except
end;
end;

</pre>

Allerdings setzt das vorraus das JEDWEIGE COM Funktion erst nach dem CoInitialize() aufgerufen wird. Sollte also im Constructor des Threads schon auf COM zugegriffen werden dann muß in der Unit Initialization/Finalization Sektion beide Aufrufe erfolgen. Im Grunde halte ich das für sicherer und stören tut es auch nicht.

Gruß hage

[Helmut Schumacher]

<pre>Noch eine Frage an Hagen.
Wenn ich im Thread in der Procedure Execute
den Aufruf von CoInitialize(NIL) mache,
darf ich dann CoUninitialize auch im Destructor
des Thread aufrufen? Oder auch nur in Execute?

Mfg
Helmut</pre&gt

[Robert Marquardt]

Sicherheitshalber alles im Execute machen. Der Destruktor ist doch wieder im Hauptthread angesiedelt. Execute ist das einzig relevante im Thread. Alles andere ist eh nur objektorientierter Zucker obendrauf. Nur Execute laeuft garantiert im Kontext des Threads und CoInitialize und CoUniitialize sind auf den Threadkontext bezogen, sonst muesstest du sie ja nicht extra aufrufen

[Hagen Reddmann]

Hi Robert,

ich bin mir da nicht ganz sicher. Aus Sicht einer sicheren Programmierung gebe ich dir Recht, wenn CoInitialize() im .Execute aufgerufen wird so sollte auch CoUnitialize dort aufgerufen werden. Allerdings meine ich das man auf Grund des sauberem Source so macht, und nicht weil es technisch unbedingt nötig wäre. <br>
Sollte CoInitialize()/CoUninitialize() wirklich Threadabhängig sein ?? Ich glaube es ist nur Prozessabhänig, somit würde selbst ein Aufruf in der Unit Initialization/Finalization Sektion ausreichen um denoch mit den Threads korrekt arbeiten zu können.<br>

Wichtig ist nur eines, zu jedem CoInitialize() Aufruf muß bei der Beendigung ein CoUnitialize Aufruf erfolgen.

Gruß Hage

[Helmut Schumacher]

<pre>Hallo Hagen,
wenn ich dich richtig verstehe, dann könnte man
den Aufruf im Hauptthread auch machen, selbst
wenn man den Unterthread gar nicht startet. Also kein Com-Objekt instanziert.
Das würde bedeuten, das man eigendlich immer
CoInitialize(nil); aufrufen könnte.

Helmut

PS.
ich werde gleich mal einen Test machen, bei dem in CoInitialize(nil); vom Hauptthred aufrufe.</pre&gt

[Helmut Schumacher]

<pre> Hallo zusammen,
mein Test hat ergeben, daß CoInitialize(nil);
im Unterthread aufgerufen werden muß.

Helmut</pre&gt

[Hagen Reddmann]

Danke für diese Info, ich war zu faul für einen Test. Es bedeutet dann auch das CoInitialize() tatsächlich an den Threadcontext gebunden ist.

Gruß Hage

[Robert Marquardt]

Das hatte ich mir schon gedacht. COM ist streng an den Thread gebunden sonst muesste man CoInitialize nur einmal im Hauptthread aufrufen (was ja automatisch geschieht). Das CoUninitialize muss dann auch im Thread stehen, weil ich weiss das Windows nirgendwo so schlau gemacht ist das es den richtigen Threadkontext zuordnen koennte

[Hagen Reddmann]

Naja, die meisten Kernel Zuordnungen sind Prozessgebunden. CoInitialize() wäre da eher die Ausnahme von der Regel, aber was soll's man muß es halt nur wissen.

Gruß hage