Klassenbibliotheken für crosscommexe???

Hmm ich weiss nicht ob das eine gute Idee ist. Was willst du genau erreichen?
Für mich tönt dein Beitrag so als ob du mit beschränkten C++ Kenntnissen (Und ich entnehme dem auch im allgemeinen eher niedrige OOP Kenntnisse.) Und vorallem eine nicht offiziell dokumentierte Schnittstelle verwenden?
Ich kann dir leider nichts genaueres zur CrossCom sagen, doch tönt mir dein Vorhaben ein wenig auf wackeligen Beinen.

Zu Kuka kann ich leider nichts beitragen, ich habe zum Glück nur mit Robotern zu tun, die etwas C++-freundlicher sind.

Aber ich muss simeonw in einigen Punkten zustimmen. Deine Frage zu den Programmiersprachen deutet in der Tat darauf hin, dass du von COM nicht viel Ahnung hast.
http://de.wikipedia.org/wiki/Component_Object_Model

COM-Clients in Visual C++ kann man auf viele verschiedene Arten schreiben:

z.B. Compiler COM Support
http://msdn.microsoft.com/de-de/library/8etzzkb6.aspx
oder die entsprechenden Smart Pointer Klassen in der ATL.

Late Binding (wenn die Kuka Software das unterstützt) über die entsprechenden Klassen in der MFC oder auch zu Fuß
http://blog.kalmbachnet.de/?postid=63

Wenn du solide C++ Kenntnisse hast, sollten das keine böhmischen Dörfer für dich sein ...
Ich persönlich muss allerdings sagen, dass ich komplizierte COM-Geschichten in C++ lieber vermeide.

Hoffe das hilft etwas

Urmel

Hi,

was den C++ Teil angeht, kann ich dir leider nicht konkrekt weiterhelfen, aber während mein Wohnzimmer
durch die weiblichen Familienteile und POPSTARS belegt war, habe ich mal ein rudimentäres
Delphi Beispiel zusammengebastelt, das für dich möglicherweise nachvollziehbarer sein dürfte als VB-Code.
Vielleicht bringt es dich der Sache ja etwas näher....

Die Anwendung besteht aus einem kleinen Fenster mit einer Textbox, einem Button und einem Memofeld.
(siehe angehängtes Bild)
Nach Eingabe eines Variablenamens in die Textbox und Drücken des Buttons, wird im Memofeld das Ergebnis
von CrossComm.ShowVar angezeigt; ziemlich trivial....

Hier der Code dazu (ohne ausführliche Fehlerbehandlung):

unit Unit1;


interface


uses
  Forms, StdCtrls, Classes, Controls;


type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Memo1: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    oCross: variant;
  end;


var
  Form1: TForm1;


implementation
{$R *.DFM}


uses
  comobj, dialogs;


procedure TForm1.FormCreate(Sender: TObject);
begin
  oCross := CreateOleObject('CrossCommEXE.CrossCommand');
  oCross.Init(Unassigned);       // wenn die Anwendung auf CrossComm-Ereignisse reagieren soll (z.B. für SetInfoOn() etc.)
                                 // dann muß hier statt "Unassigned" ein ComServer-Objekt übergeben werden, das
                                 // das entsprechende Interface implementiert und so über die Ereignisse "informiert" wird


  if oCross.ConnectToCross('DasTestProjekt', 0) = '0' then
    ShowMessage('CrossComm-Init. fehlgeschlagen!');
end;




procedure TForm1.FormDestroy(Sender: TObject);
begin
  try
    oCross.ServerOff;
  except
  end;
  oCross := Unassigned;
end;




procedure TForm1.Button1Click(Sender: TObject);
var
  s: string;
begin
  if oCross.ShowVar(Edit1.Text, s) = '0' then
    Memo1.Text := '<Variable unbekannt!>'
  else
    Memo1.Text := s;
end;


end.

gruß
rmac

PS.: Ich habe auf diesem Wege eine komplette Client/Server-basierte TouchScreen-Anwendung mit Paletten-/Teile-/Benutzer-
Verwaltung, Parametrierung, Protokollierung und jede Menge anderem Firlefanz zusammengebaut.

Zitat von rmac

Delphi Beispiel zusammengebastelt, das für dich möglicherweise nachvollziehbarer sein dürfte als VB-Code.
Vielleicht bringt es dich der Sache ja etwas näher....

Ah, das ist doch schon mal hilfreich.

CreateOleObject deutet schon mal darauf hin, dass es da eine IDispatch-Schnittstelle gibt.
http://en.wikipedia.org/wiki/IDispatch

Dann geht es in VC so wie in dem LateBinding-Link in meinem Posting weiter oben. Im C++-Builder dürfte es so ähnlich aussehen wie in Delphi, kommt drauf an welchen Compiler du hast.

Von allen COM-Varianten ist die clientseitig am einfachsten zu programmieren (und am langsamsten), das sollte in allen gängigen Programmiersprachen in der Tat recht ähnlich gehen.

Grüße

Urmel

Zitat von Urmel

[...]Von allen COM-Varianten ist die clientseitig am einfachsten zu programmieren (und am langsamsten), das sollte in allen gängigen Programmiersprachen in der Tat recht ähnlich gehen.[...]

Jo, da hast du wohl recht.
Aber der Vorteil beim Late-Binding ist eine gewisse Unabhängigkeit vom Versionsstand des Objektes, da ja
über den Klassenname aufgelöst wird. (Andererseits weiß ich auch nicht wie oft KUKA neue Releases nachgeschoben hat)
Den Geschwindigkeitsverlust stufe ich nicht als so kritisch ein, da CrossComm ohnehin nicht echtzeitfähig ist.
Überhaupt sind meine Erfahrungen mit der CrossComm-Performance nicht sonderlich berauschend und ich glaube
nicht, dass das (nur) an der IDispatch-Schnittstelle liegt.
Hängt in meinen Augen auch stark von der Rechnerleistung ab: bei meinem letzten Projekt (KRC1 R2.2.8, CPU 100MHz,
64MB Hauptspeicher !!!) war das echt super-lahm....
Dürfte so im Leistungsbereich von heutigen mittelpreisigen Handys oder guten MP3-Playern liegen....

Naja, was solls, Hauptsache funktioniert...
gruß
rmac