pythoncom Spezialitäten im Vergleich zu COM in c#

Python in C/C++ embedden, C-Module, ctypes, Cython, SWIG, SIP etc sind hier richtig.
derdigge
User
Beiträge: 5
Registriert: Montag 24. Juli 2017, 17:44

pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon derdigge » Montag 24. Juli 2017, 18:10

Hallo Liebes Forum.

Ich stehe vor folgender Problematik. Mir fehlt die Erfahrung im Umgang mit pythoncom. Im c# habe ich die Möglichkeit com Objekte folgendermaßen
aufzurunfen.

  1. m_tpr = new TaiPanRealtime();    // startet eine com Instanz
  2.  
  3. m_datastream = m_tpr.DataStream as DataStream;    // dockt an die Datastream Objekt
  4.  
  5. var datastreamEx = m_datastream as IDataStreamEx;    // diese "Magie" hier würde ich gern mit pythoncom nutzen
  6.  
  7. datastreamEx.EnableExEvent();    // diese Methode ändert den eventhandler auf ein singleevent welches als call den typ des events enthält. Das ist mein Ziel übrigens im python.
  8.  
  9. m_datastream.ExEvent += M_datastream_ExEvent;    // hier wird an den eventhandler angedockt.


Dies versuche ich in Python like:
  1. m_tpr = win32com.client.Dispatch("TaiPanRealtime.Application")        # startet eine COM instanz
  2.  
  3. stream = m_tpr.DataStream      # Andocken an das Stream Objekt
  4.  
  5. stream.EnableExEvent();       # kennt er nicht: object has no attribute 'EnableExEvent'
  6.  
  7. events = win32com.client.WithEvents( stream , EventHandler )


Lasse ich den teil von stream = com.DataStream weg kann ich Events empfangen und verarbeiten. Jedoch brauche ich für jede eventart eine funktion in der EventHandler Klasse. Das ist zum einen total umständlich und führt zum einfrieren bei richtig Traffic auf der Schnittstelle, wenn da events nicht abgedeckt sind.

Vielleicht hat jemand Erfahrungen mit pythoncom? Oder mit c# und versteht besser wie der Code oben sich verhält?

Danke fürs Lesen.

Viele Grüße
derdigge
Zuletzt geändert von Anonymous am Montag 24. Juli 2017, 18:55, insgesamt 1-mal geändert.
Grund: Quelltext in Codebox-Tags gesetzt.
BlackJack

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon BlackJack » Montag 24. Juli 2017, 19:35

@derdigge: Also wenn ich diesen Beitrag im Lenz+Partner-Forum richtig verstanden habe dann werden bei diesem `ExEvent` genau so viele Ereignisse erzeugt, bloss wird immer der selbe Handler aufgerufen und der Typ des Ereignisses wird als Argument mitübergeben. Ich sehe da jetzt ehrlich gesagt keinen Vorteil die Verteilung selbst zu machen. Die ist potentiell in `win32com` effizienter in C implementiert. Und falls es dort auch in Python-Implementiert ist, müsste man sich wenigstens die Arbeit nicht mehrfach machen.

Was passiert denn wenn man für ein Ereignis keine Methode auf der `EventHandler`-Klasse definiert hat? Was ist so umständlich daran die zu definieren?
derdigge
User
Beiträge: 5
Registriert: Montag 24. Juli 2017, 17:44

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon derdigge » Montag 24. Juli 2017, 22:08

Hallo Blackjack.

Es ist so.(Schlussfolgerung aus meinen Beobachtungen) Das ein COM event einen Timeout hat. Es wird gefeuert und landet dann im Handler. Wenn es dort keine Verwendung nach Zeit x erfährt timeoutet es. Da ich aber nicht alle Fälle abdecke? habe ich bei mehreren 1000 Ereignissen pro Sekunde "Stau im Elbtunnel".

Um die Nachmittagszeit ist der meiste Traffic auf dem Handler. Da friert er mir ein und ich habe Zeitweise für 30-40 Minuten gar keine Events mehr.
Ich versuche es zu verstehen daher habe ich mit einer Funktion die mir die Methoden etc von com Objekten ausgibt. Es ist ein Paste aus dem Internetz, verbesserungsvorschläge - verry welcome. [Pastebin]https://pastebin.com/2N8fidNu[/Pastebin]
Aus dieser konnte ich verstehen, das events(events = win32com.client.WithEvents( stream , EventHandler )) folgende Ereignisse feuert.

# {1: 'OnBezahlt', 2: 'OnBrief', 3: 'OnGeld', 4: 'OnBriefMT', 5: 'OnGeldMT', 6: 'OnStatus', 7: 'OnAktuellMeldung', 8: 'OnOpenInterest', 9: 'OnKorrekturOpen', 10: 'OnKorrekturHigh', 11: 'OnKorrekturLow', 12: 'OnKorrekturVolume', 13: 'OnIndiKurs', 14: 'OnNews', 15: 'OnReload', 16: 'OnExEvent'}

Wobei OnReload und OnExEvent nicht dokumentiert sind. Daraus habe ich halt jetzt folgenden Handler geknetet:

  1.     class EventHandler:
  2.  
  3.         #   {1: 'OnBezahlt', 2: 'OnBrief', 3: 'OnGeld', 4: 'OnBriefMT', 5: 'OnGeldMT', 6: 'OnStatus', 7: 'OnAktuellMeldung', 8: 'OnOpenInterest',
  4.         #   9: 'OnKorrekturOpen', 10: 'OnKorrekturHigh', 11: 'OnKorrekturLow', 12: 'OnKorrekturVolume', 13: 'OnIndiKurs', 14: 'OnNews', 15: 'OnReload', 16: 'OnExEvent'}
  5.  
  6.         def OnBezahlt(self, SymbolNr, Kurs, Volume, Zeit):
  7.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn ein neuer Bezahltkurs für ein Symbol aus der Überwachungsliste eintrifft.
  8.             set_value(self, SymbolNr, Kurs, Volume, Zeit)
  9.             #logger("OnBezahlt")
  10.             return
  11.  
  12.         def OnBrief(self, SymbolNr, Kurs, Volume, Zeit):
  13.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn ein neuer Briefkurs für ein Symbol aus der Überwachungsliste eintrifft.
  14.             return
  15.  
  16.         def OnGeld(self, SymbolNr, Kurs, Volume, Zeit):
  17.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn ein neuer Gledkurs für ein Symbol aus der Überwachungsliste eintrifft.
  18.             return
  19.  
  20.         def OnBriefMT(self, Position, SymbolNr, Kurs, Volume, Zeit):
  21.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn ein neuer Briefkurs (Markttiefe) für ein Symbol aus der Überwachungsliste eintrifft.
  22.             return
  23.  
  24.         def OnGeldMT(self, Position, SymbolNr, Kurs, Volume, Zeit):
  25.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn ein neuer Gledkurs (Markttiefe) für ein Symbol aus der Überwachungsliste eintrifft.
  26.             return
  27.  
  28.         def OnStatus(self, code):
  29.             #   Dieses Ereignis tritt ein (wird gefeuert), wenn eine Statusveränderung bzgl. der Verbindung von Tai-Pan Realtime eintrifft.
  30.             print(code)
  31.  
  32.         def OnAktuellMeldung(self, url):
  33.             #   Dieses Ereignis wird gefeuert, wenn eine neue Aktuell-Meldung zu Tai-Pan Realtime verfügbar ist.
  34.             return
  35.  
  36.         def OnOpenInterest(self, SymbolNr, OpenInterest, Zeit):
  37.             #   Dieses Ereignis wird gefeuert, wenn ein neuer Wert für das Open Interest geliefert wird.
  38.             return
  39.  
  40.         def OnKorrekturOpen(self, SymbolNr, Kurs, Volume, Zeit):
  41.             #   Diese Ereignisse werden gefeuert, wenn eine Korrektur zu einem Symbol geliefert wird. Die Art der Korrektur wird durch das Event definiert.
  42.             return
  43.  
  44.         def OnKorrekturHigh(self, SymbolNr, Kurs, Volume, Zeit):
  45.             #   Diese Ereignisse werden gefeuert, wenn eine Korrektur zu einem Symbol geliefert wird. Die Art der Korrektur wird durch das Event definiert.
  46.             return
  47.  
  48.         def OnKorrekturLow(self, SymbolNr, Kurs, Volume, Zeit):
  49.             #   Diese Ereignisse werden gefeuert, wenn eine Korrektur zu einem Symbol geliefert wird. Die Art der Korrektur wird durch das Event definiert.
  50.             return
  51.  
  52.         def OnKorrekturVolume(self, SymbolNr, Kurs, Volume, Zeit):
  53.             #   Diese Ereignisse werden gefeuert, wenn eine Korrektur zu einem Symbol geliefert wird. Die Art der Korrektur wird durch das Event definiert.
  54.             return
  55.  
  56.         def OnIndiKurs(self, SymbolNr, Kurs, Volume, Zeit):
  57.             #   Dieses Ereignis wird gefeuert, wenn ein neuer Indikativer Kurs geliefert wird. Dies ist z.B. bei Open-, Intraday- oder Schluss-Auktionen der Fall.
  58.             return
  59.  
  60.         def OnNews(self, Zeit, sWPKs):
  61.             #   Dieses Ereignis wird gefeurt, wenn eine neue Newsmeldung geliefert wird. Geliefert wird die neuste News mit der Spalte "Wertpapiere" des Newsfensters und des Zeitstempels.
  62.             return
  63.  
  64.         def OnReload(self):
  65.             #   not in documentation
  66.             return
  67.  
  68.         def OnExEvent(self, nEventID, SymbolNr, Kurs, Volume, Zeit, LongValue):
  69.             #   not in documentation
  70.             logger( "exevent" + nEventID )
  71.             return


Hier nochmal als Pastebin
[Pastebin]https://pastebin.com/82C9afVd[/Pastebin]

Heute Abend hat er erstmal funktioniert™. Es ist aber auch nichts los. Ich arbeite mit sublimetext und python in der cmd. Da ich nicht so der "Windowstyp" bin, kenne ich keine andere Möglichkeit. Spyder habe ich unter Windows nicht ans laufen gekriegt. Daher wüsste ich nun nicht, wie ich es besser machen könnte zu sehen wo ein Event "Kleben bleibt". bzw. wie man eine solche COM vernünftig reverse engineered. Nach dem Source Code zum selber stöbern, brauche ich wohl nicht zu fragen bei Lenz und Partner. ;)

Meine Frage hier zielt halt in die Richtung, wie die Finessen beim Aufruf von comobjekten mit pythoncom sind. Es muss ja möglich sein?


Danke und Grüße
derdigge
BlackJack

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon BlackJack » Dienstag 25. Juli 2017, 00:41

@derdigge: Zum Code der die Rückrufmethoden ermittelt:

Wozu ist das ``try``/``except`` da? Welcher Attributname taucht denn in `dir()` auf, lässt sich dann aber mit `getattr()` nicht abfragen? Und welche Ausnahme wird da erwartet/ausgelöst? Nackte ``except:`` ohne Konkrete Ausnahme, die dazu einfach *gar nichts* machen, führen gerne mal zu laaaaangen Fehlersuchen wenn da irgendwas auftaucht was man gar nicht erwartet hat.

Die Zeichenkettendarstellung von einem Typ zu vergleichen ist keine gute Idee, denn so wirklich spezifiziert ist das Ergebnis nicht. Im `types`-Modul gibt es `types.InstanceType` das man für Vergleiche heranziehen kann.

Was Du `method` nennst muss keine Methode sein. Das ist erst einmal irgendein Attribut. Und auch `sub_method` ist keine Methode sondern eine Zeichenkette/ein Attributname. Da muss auch keine Methode dahinter stehen.

Ich würde bei den `dir()`-Aufrufen noch ein `sorted()` verwenden um die Ausgabe ein wenig übersichtlicher zu haben. Ungetestet:
  1. from types import InstanceType
  2.  
  3.  
  4. def show_comkeys(comobj):
  5.     for name in sorted(dir(comobj)):
  6.         attribute = getattr(comobj, name)
  7.         if isinstance(attribute, InstanceType):
  8.             print(name)
  9.             for sub_name in sorted(dir(attribute)):
  10.                 if (
  11.                     not sub_name.startswith('_')
  12.                     and 'clsid' not in sub_name.lower()
  13.                 ):
  14.                     print('\t' + sub_name)
  15.         else:
  16.             print('\t', attribute)

Mit dem `EventHandler` hast Du Dir ja die Arbeit jetzt schon gemacht. Die Kommentare würden wohl ganz gute Docstrings abgeben.

Wenn in einer Funktion/Methode nichts steht würde ich eher ein ``pass`` als ein ``return`` ohne Rückgabewert verwenden. Und das in Funktionen/Methoden in denen etwas steht dann auch entfernen.

Für Methoden die man nicht wirklich implementieren möchte kann man auch einmal eine Methode schreiben die beliebige Argumente entgegen nimmt, nichts tut, und dann die Namen der zu ignorierenden Methoden auch alle an diese eine Methode binden.

Je nach dem wie win32com die Methoden ermittelt könnte man vielleicht auch einfach mit `__getattribute__()` dafür sorgen das bei jedem Attribut das es nicht auf dem Objekt gibt, eine solche Dummy-Methode geliefert wird.
derdigge
User
Beiträge: 5
Registriert: Montag 24. Juli 2017, 17:44

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon derdigge » Dienstag 25. Juli 2017, 09:57

Moin BlackJack!

Wie gesagt es ist ein Copy and Paste aus dem Internetz. Mein Types hat kein InstanceType :)

  1. (Pdb) from types import *
  2. (Pdb) types.InstanceType
  3. *** AttributeError: module 'types' has no attribute 'InstanceType'


bzw.

  1. (Pdb) from types import InstanceType
  2. *** ImportError: cannot import name 'InstanceType'


Anyway. Das geht glaube ich etwas in die falsche Richtung. Es muss doch, ganz allgemein nicht auf das derzeitige Problem beschränkt, Objekte gezielt(er) anzufragen? Als Beispiel mal an einer Watchliste von Taipan:

im C#:
  1.  
  2. // liefert ein COM Objekt mit Methoden : Count | Item | Name | Nr
  3. TPRTListen = (IListen)TPRTDataBase.WatchListen;
  4. TPRTWatchListe = (IWatchListe)TPRTListen[1];
  5.  
  6. //  liefert eine COM Objekt mit anderen Methoden: Add | Remove | RemoveAll
  7. TPRTListen = (IListen)TPRTDataBase.WatchListen;
  8. TPRTWatchliste2 = (IWatchListe2)TPRTListen[1];
  9.  


Diese Praktik ist in c# nichts ungewöhnliches und beschränkt sich nicht auf die COM der TaiPan.
Mir ist durchaus bewusst, das mein Anliegen etwas pikant/speziell ist.

Gruß
derdigge
BlackJack

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon BlackJack » Dienstag 25. Juli 2017, 11:53

@derdigge: Dann verwendest Du Python 3. Dann wundert mich aber das Du ”old style classes”-Objekte hast, denn die haben diesen Typ `types.InstanceType` in Python 2 und dieser Typ wird als ``"<type 'instance'>"`` als `str()` dargestellt. In Python 3 gibt es diesen Typ nicht mehr und deshalb auch `InstanceType` nicht mehr im `types`-Modul.

Die Objekte haben in C# ja alle Methoden. Die Deklarationen beziehungsweise das casten mit Interfaces erlauben ja letztendlich nicht den Zugriff, sondern schränken ihn auf das Interface ein.

``TPRTDataBase.WatchListen[1]`` hat in Deinem Beispiel die Methoden Add, Count, Item, Name, Nr, Remove, und RemoveAll. Und vielleicht auch noch andere. In Python könnte man einfach auf alle zugreifen ganz ohne casten zu müssen, denn es gibt die statische Typisierung und damit die Beschränkungen durch Interfaces nicht. Nur hast Du da in Python ja kein Python-Objekt sondern ein Proxyobjekt das irgendwie wissen muss wie es Zugriffe von Python aus an das COM-Objekt weiterleiten muss.

Man muss sich dazu wohl näher mit der COM-Schnittstelle und deren Typsystem beschäftigen.

Das die pywin32-Dokumentation als CHM-Datei vorliegt hilft nicht gerade wenn man von einem Linux-System aus helfen möchte und sich das nicht runterladen mag. :-)

Es gibt aber wohl eine `CastTo()`-Funktion in `win32com.client`. Schau mal ob und wie man die verwenden kann.
derdigge
User
Beiträge: 5
Registriert: Montag 24. Juli 2017, 17:44

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon derdigge » Dienstag 25. Juli 2017, 16:22

``TPRTDataBase.WatchListen[1]`` hat in Deinem Beispiel die Methoden Add, Count, Item, Name, Nr, Remove, und RemoveAll. Und vielleicht auch noch andere. In Python könnte man einfach auf alle zugreifen ganz ohne casten zu müssen, denn es gibt die statische Typisierung und damit die Beschränkungen durch Interfaces nicht. Nur hast Du da in Python ja kein Python-Objekt sondern ein Proxyobjekt das irgendwie wissen muss wie es Zugriffe von Python aus an das COM-Objekt weiterleiten muss.


!= True

Das is ja genau der Punkt es sind zwei unterschiedliche Objekte. Wie unten geschrieben kommt es drauf an ( in c# ) wie es gecastet wird.


Es gibt aber wohl eine `CastTo()`-Funktion in `win32com.client`. Schau mal ob und wie man die verwenden kann.


Dit isset! Du hast et voll druff.

https://mail.python.org/pipermail/pytho ... 01728.html
In der Mailing List steht es beschrieben. For example:

C#:
  1. // Allgemeine DeklarationTaiPanRealtime TPRTObjekt;
  2. TPRTObjekt = new TaiPanRealtime();
  3. DataBase TPRTDataBase;
  4. TPRTDataBase = (DataBase)TPRTObjekt.DataBase;
  5.  
  6. TPRTListen = (IListen)TPRTDataBase.WatchListen;
  7. TPRTWatchliste2 = (IWatchListe2)TPRTListen[1];


ist in Python:
  1. from win32com.client import CastTo
  2. import win32com.client
  3.  
  4. l_com = win32com.client.Dispatch("TaiPanRealtime.Application") # entspricht TPRTObjekt = new TaiPanRealtime();
  5. wl1 = CastTo( l_com.DataBase.WatchListen , "IIListen" ) # entspricht TPRTListen = (IListen)TPRTDataBase.WatchListen;
  6. wl2 = CastTo( wl1[0], "IWatchListe2" ) # entspricht TPRTWatchliste2 = (IWatchListe2)TPRTListen[1];


an wl2 habe ich nun alle methoden der IWatchliste2 und nichtmehr die der IWatchListe. Somit ist mein Verständnisproblem beseitigt. Danke vielmals. Dieses Verhaltenn kann nun natürlich auf die Ursprüngliche Problemstellung angewandt werden.

Danke und Gruß
BlackJack

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon BlackJack » Dienstag 25. Juli 2017, 16:37

@derdigge: Okay, das ist ein bisschen verwirrend — man kann in C# den Cast nicht überladen aber benutzerdefinierte Typkonvertierungen, was letztendlich dann doch nach überladenen Casts aussieht. Abgefahren. :-)
derdigge
User
Beiträge: 5
Registriert: Montag 24. Juli 2017, 17:44

Re: pythoncom Spezialitäten im Vergleich zu COM in c#

Beitragvon derdigge » Dienstag 25. Juli 2017, 18:26

Mich verwirrt es auch noch etwas :) Ich bin nach wie vor noch nicht am Ziel. Die Regentage sind dennoch überraschend produktiv :]

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder