qtforum.de

Hallo,

ich habe die Suchfunktion benutzt, aber nichts gefunden, was mich mit meinem Problem weiterbringt.

Ich programmiere gerade ein Software für einen Kunden, der diese dann wiederum aus seinem Programm heraus aufruft.

Jetzt muss ich dem Programm auf irgend eine Art und Weise mitteilen, in welchem Zustand sich mein Programm gerade befindet. Wir haben uns dabei auf die COM-Schnittstelle geeinigt, da das Hauptprogramm so oder so nur unter Windows läuft.

Allerdings habe ich keinen blassen schimmer, wie ich das ganze verhackstückeln soll. Habe noch nie COM-Programmierung gemacht, und stehe deswegen etwas auf dem Schaluch. Auch die Examples die bei Qt dabei sind bringen mich nicht wirklich nach vorne.

Kann mir da irgendjemand ein paar Tipps oder Links geben, bei denen ich mir das nötige Wissen aneignen kann. Das wäre echt super.

bp

Wenn Du COM koenntest, und die kommerzielle version von QT haettest, wuerdest du dir das activeQT "framework" anschauen, sagen "Aha" und los gaeng es.

Wenn du Nix mit COM anfangen kannst, aber COM Schnittstellen programmieren musst, err darfst, wirst Du dich um das einarbeiten ned herumdruecken koennen. Und COM iss alles andere als trivial, schon mal viel spass dabei

ActiveQt bietet dir bissi unterstuetzung bei COM,aber ebend nur bissi. Ohne COM zu koennen wirst du mit dem Zeugs auch genau NULL anfangen koennen.

Ciao ...

Das habe ich schon befürchtet.
Hast du denn ein paar tutorials oder bücher die du mir empfehlen kannst.
Zuhause habe ich auch noch die Win32API von irgend sonem Guru.
Wird wohl meine erste Anlufstelle sein, wenn ich gleich Feierabend habe.

bp

Ihr scheint noch in der Planungsphase zu sein: Was spricht gegen eine TCP-Verbindung? Einfach, plattformunabhängig, flexibel.

Gruß,
FaS

Falls noch möglich würde ich auch TCP nehmen, ansonsten gibt es ein Buch von Microsoft Press "Inside COM", oder so ähnlich, das ist gut.

Richtig empfehlen kann ich nix.

Inside COM iss scho fast Pflicht, weils eines der besseren Buecher ueber Com ist, und halt eben COM erklaert mit wenigstens ein bisschen Abstraktion von ner fertigen Implementierung mit ner Lib.
Lass dich auf keinen Fall auf literatur über Mfc + COM ein. Da lernst meisst ned viel über COM sondern da wird mehr über die Mfc hergebetet

Besser sind Bücher über die ATL, wobei es da ned viele gibt. Ausserdem isses einfacher ne ATL Anwendung mit der QT zu verheiraten als Mfc mit QT, bzw ne QT Anwendung mit Mfc Bibs zu verlinken.

In COM reinzukommen iss halt bissi ... naja ... sagen wir mal umständlich und ned wirklich intuitiv.

Falls Du ne Wahl hasst, was anderes zu nehmen, ergreif die Chance !

COM Schnittstellen benutzten, das koennt man noch recht einfach hinkriegen. (DirectX programmieren ja auch viele) aber selber COM Schnittstellen bereitstellen, iss schon aufwendig und gibt tonnen an fallstricken, besonders wenn mann es noch nie gemacht hat.

Muesste ich heut eine unserer (QT)Anwendungen auf COM umstellen, wuerd ich der Qt anwendung nen Command Interface über nen IPC mechanismus (TCP z.b. wie oben empfohlen) implementieren fuer ne fernsteuerung, und fuer die COM Anbindung dann ne ActiveX-komponente, die Das COM auf das Commandinterface mappt. Klingt zwar umstaendlich, isss IMHO aber vielleicht doch einfacher als die QT anwendung direkt auf COM umzustellen ....

Ciao ...

Danke für die Anmerkungen und Hilfen.
Es spricht nichts gegen TCP oder ne andere Art der Kommunikation.
Plattformübergreifend muss das ganze aber nicht sein, da das Hauptprogramm nur unter Windows lauffähig ist, und auch währscheinlich nie, niemals nie portiert wird. Aber das soll nicht mein Problem sein.
Ich schaue mir das ganze mal an und werde dann entscheiden was ich machen soll.
Mitlerweile bin ich auch schon der Meinung, dass wir etwas anderes nehmen sollten.

bp

Was/wieviel/wieoft tauscht du Daten mit dem Hauptprogramm aus?
Evtl wäre dann auch noch Shared Meomory eine alternative. Ist die Frage was an Daten gesendet wird und ob du remote Fähigsein musst.
Auch wäre SOAP noch etwas für die Kommunikation, oder wenn du was probieren willst DBUS.