ich schildere kurz mal meine Herausforderung ^^:
Es gibt ein VoIP-SDK, welches ich unter .NET C# nutzen konnte um
Sprachverbindungen zwischen 2 Stationen (Windows XP PCs) zu ermöglichen.
Da dieses SDK unter DotNET auf ActiveX aufbaut, muss eine OCX Datei ins
System registriert werden, dies ist aber nicht gewünscht und sollte umgangen werden.

Jetzt bietet das SDK aber auch Unterstützung für C++ an, eine Lib/DLL sowie eine
Beispielanwendung (welche die MFC nutzt) sind mitgeliefert.

Da man in C# mit DLLImport nur Funktionen, aber keine (nötigen) Klassen aus unmanaged Code importieren kann, wollte ich den Umweg über eine Managed C++ Library gehen, dafür wollte ich die gleiche DotNET Anwendung aber erst einmal als Unmanaged C++ realisieren.

So, der Punkt wo ich gerade feststecke: Weil ich unter unmanaged C++ versuche das ganze als Konsolenanwendung zu realisieren, gibt es ein kleines Problem.
Und zwar, sobald die Verbindung aufgebaut werden soll, muss sich das Programm in einer Standardmeldeschleife befinden, damit es sich nicht beendet. Ansonsten läuft es einfach weiter (bis zum Ende).

Unter DotNET habe ich das wie folgt gelöst:

// Reference auf System.Windows.Forms hinzugefügt
System.Windows.Forms.Application.Run(); //Standardmelgeschleife gestartet

Nun habe ich aber keine Ahnung wie/wo ich das unter C++ und eventuell mit der MFC lösen kann, ich hoffe das mir hier einer helfen kann.

Danke im voraus!

PS: Hier ein Artikel wie man eine Unmanaged C++ DLL unter DotNET nutzen kann, mit dem Umweg über einen Managed C++ DLL:
http://codeguru.earthweb.com/cpp/cpp/cpp_managed/interop/article.php/c6867/

while (GetMessage(...

Aber wie terminiert das Programm denn?

Dann bau doch keine Consolen Anwendung sondern eine Windows Anwendung.
Dann kannst Du acuh eine eigene MessageLoop einbauen.

while (GetMessage(...

Aber wie terminiert das Programm denn?

Eine Windows-Anwendung ist nicht praktikabel, weil ich später eh eine DLL daraus machen will (werde).

Eine eigene MessageLoop würde ich gerne bauen, aber ich weiß leider nicht welche Nachrichten ich abfragen muss.
Und ob es reicht einfach eine Endlosschleife zu integrieren, bezweifle ich (ich habe es aber noch nicht getestet).

Momentan habe ich es etwas anders gelöst, ohne den Lerneffekt (wenn man so will).
Ich habe ein neues Managed C++ Projekt angefangen und dort durch meine bisherigen Erfahrungen mit dem unmanaged Code alles soweit hinbekommen das ich dann mit System::Windows::Forms::Application::Run(); alles soweit funktioniert.

Momentan kämpfe ich damit wie ich einen LPCTSTR aus C++ in einen .NET System::String umwandeln kann..
Ich denke ich gehe den Umweg über ein CharArray.

Ich denke ich werde das auch so lassen, aber mich interessiert brennent ob/wie man das Problem sonst beheben könnte (die Endlosschleife werde ich nachher mal ausprobieren).

Erstmal danke für die Anregung.

Achso, das SDK wirft Events, so kann ich reagieren und das Programm ggf. beenden.

Gruß
Florian

Edit: Kleine Änderungen.

Der STA Thread in dem die MessageLoop läuft muss autark sein. Deshlab ist eine Windows GUI Applikation hier genau der richtige Ansatz!
Gerade weil die Events asynchron letzten Endes die Message Loop benötigen kann Dein DLL Ansatz nur in die Hose gehen...

Außer Du möchtest die Funktion aus der DLL aufrufen und sie kehrt nicht zurück.

Oder Du musst das ganze in der DLL in einen eigenen Thread auslagern. Aber auch hier ist eine MessageLoop im Stile eine Windows UI Programmes der richtige Ansatz.

Wenn Du jetzt straucheslt einen char* nach System::String zu konvertieren wünsche ich Dir weiterhin Happy Coding.
HOW TO: Convert from System::String* to Char* in Visual C++ .NET
http://support.microsoft.com/?kbid=311259

Das hake mal ganz schnell ab. Eine DLL mit MessageLoop?
Das kann doch nicht gehen.

Der STA Thread in dem die MessageLoop läuft muss autark sein. Deshlab ist eine Windows GUI Applikation hier genau der richtige Ansatz!
Gerade weil die Events asynchron letzten Endes die Message Loop benötigen kann Dein DLL Ansatz nur in die Hose gehen...

Außer Du möchtest die Funktion aus der DLL aufrufen und sie kehrt nicht zurück.

Oder Du musst das ganze in der DLL in einen eigenen Thread auslagern. Aber auch hier ist eine MessageLoop im Stile eine Windows UI Programmes der richtige Ansatz.

Wenn Du jetzt straucheslt einen char* nach System::String zu konvertieren wünsche ich Dir weiterhin Happy Coding.
HOW TO: Convert from System::String* to Char* in Visual C++ .NET
http://support.microsoft.com/?kbid=311259

Naja, ich musste erstmal wissen das LPCTSTR ein char* ist, ich bin damals von den Grundlagen von C++ direkt auf C# umgestiegen und dort fühle ich mich auch wohl. (C++ nie richtig ausführlich gelernt)
Bloss leider musste ich in diesen Fall wieder zurück und da merkt man halt, wenn gewisses Wissen einfach nicht vorhanden ist.

Die DLL wird quasi die komplette Sprachverbindung regeln und nur Events an das aufrufende Programm zurückgeben, damit dort auf eventuelle Verbindungsabbrüche reagiert werden kann.
War wie gesagt unter DotNET alles kein Problem, man muss sich halt mit vielen Sachen nicht herumschlagen, hat zwar nicht alle Freiheiten, aber es reicht meistens doch aus.

Naja, werde mal weiterarbeiten, eventuell ist gleich Mittag, ein Kollege hat Pizza mitgebracht ^^.

Gruß
Florian