![]() |
OLE Object innerhalb von TCPServer Execute ausführen
Hi,
ich habe folgendes Problem: Wenn ich in den Indy9 Demos die Demo vom TCP Server so umschreibe, dass immer wenn das Execute Event audgeführt wird, eine Methode "ReadText" (ließt über die SAPI einen Text vor) aufgerufen wird, gehe ich so vor: AThread.Synchronize(ReadText); Synchronize ist nötig, um keinen OLE Error zu bekommen. (CoInitialize wurde nicht aufgerufen) Soweit funktioniert alles. Jetzt habe ich ein Project, in dem ich den TCP Server dynamisch erzeuge und auch das Execute Event zur Laufzeit zuweise. Das Problem ist, immer wenn ich Code dirket im Execute Event ausführen will, wird die Verbindung zum Client abbgebroche und ich bekomme einen "Connection closed gracefully" Error. Daher erzeuge ich im Execute Event einen Timer mit "timeSetEvent" (Unit MMSystem). Dieser Funktion wird ein Zeiger auf eine CallbackProcedure übergeben, in welcher ich nun Code ausführen kann. Wenn ich aber ganz normal in "ReadText" aufrufe, bekomme ich oben genannten OLE Error. Wie kann ich die Methode wieder synchronisieren, oder noch besser, warum beendet der TCP Server die Verbindung, wenn ich die Methode direkt im Execute Ereigniss aufrufe? Florian |
Re: OLE Object innerhalb von TCPServer Execute ausführen
Wie wäre es einfach im Thread das COM-System selbst mittels eines CoInitialize-Aufrufs zu initialisieren?
|
Re: OLE Object innerhalb von TCPServer Execute ausführen
Es gibt die Funktion "CoInitialize"?
Auf die einfachsten Dinge kommt man zuletzt. |
Re: OLE Object innerhalb von TCPServer Execute ausführen
Also es gibt keine CoInitialize Funktion. Wie kann man das COM System den sonst initialisieren?
|
Re: OLE Object innerhalb von TCPServer Execute ausführen
Ist in ActiveX.pas deklariert.
|
Re: OLE Object innerhalb von TCPServer Execute ausführen
Achso. Ich hab in ComObj gesucht.
Danke |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:38 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz