Python és COM, II. rész

dokumentum verzi?k:

1.0 verzi?(2001N0109ú.): ezt már használhat?nak itéltem

Az el?z? cikkemet a kezd? lépések megtételéhez szántam segédanyagnak. Most igyekszem a témában egy kicsit mélyebbre ásni és a Python-COM páros kapcsolatának megértéséhez adok ?jabb informáci?kat:

A cikkben szerepl? mintaprogram kipr?bálásához sz?kséged lesz a k?vetkez?kre:

Windows 9x, Windows NT vagy Windows 2000 operáci?s rendszer.
Python 2.0 telep?t? készlet a fenti operáci?s rendszerekhez Python 1.52-h?z kicsit változtatni kell a forráson némelyikén: pl. string.lower stb.
Mark Hammond win32all csomagja
COMToCorba kipr?bálásához omniORBpy is kell
Magukra a minta programokra(COMToCorba nincs benne)

Hogyan lesz egy python objektumb?l COM objektum? Mi t?rténik a háttérben?

T?m?ren megfogalmazva a m?g?ttes infrastrukt?ra a python objektumb?l egy IDispatch objektumot csinál.

Miel?tt vázlatos lépésekben ismertetném, hogy a framework hogyan áll?tja el? ezt az IDispatch objektumot, meg kell ismerkedn?nk a policy-kkal. A policy gyakorlatilag egy k?zvet?t? a python objektum és a COM objektum k?z?tt, meghatározza hogy milyen met?dusok és attributumok érhet?ek el COM-on kereszt?l, milyen dispatch ID-kat rendel ezekhez stb. Az el?z? cikkben ismertett példákban azért nem találkoztunk policy-kkal, mert van egy alapértelmezett, a DesignatedWrapPolicy. A DesignatedWrapPolicy-nek kellenek az el?z? cikk forrásaiban szerepl? _public_methods_, _public_attrs_ stb. attributumok. Az el?regyártott policy-k k?z?l ebben a cikkben a DynamicPolicy-vel ker?l?nk k?zelebbi ismeretségbe. A policy-k python-ban kész?ltek, azaz mi is ?rhatunk egyet amennyiben a meglév?k egyike sem megfelel? számunkra.

Nézz?k mit csinál a framework pl. egy VB-b?l kiadott CreateObject hatására:

Létrehoz egy policy példányt abb?l a policy-b?l, ami specifikálva lett a python class-unkban(_reg_policy_spec_) vagy használja az alapértelmezett DesignatedWrapPolicy-t.
A policy példány létrehozza a python objektumot.
A policy objektumot becsomagolja egy IDispatch objektumba és ezt k?ldi el a kliensnek

Python-ban ?rt COM objektumok nyomk?vetése

Van mégegy beékel?d? python objektum a dispatcher, az el?z? folyamat-le?rásb?l azért maradt ki mert fogalmam sincs hogy hov? ékel?dik be pontosan. Els?sorban debugg-olásra használjuk. Az alapértelmezett DispatcherWin32trace - mint nevéb?l is látszik - a win32trace modult használja, azaz Pythonwin-ben a a Tools men?b?l elind?tva a "Trace Collector Debugging tool"-t, a megjelen? ablakban nyomon k?vethetj?k, hogy milyen h?vásokat kapott objektumunk ill. a nyomk?vetési céllal kiadott print utas?tásaink eredménye is itt jelenik meg. Ha nyomk?vetésre van sz?kség?nk, akkor azt COM komponens?nk regisztráci?jakor kell megadni ill. ha nem megfelel? az alapértelmezett DispatcherWin32trace, akkor a "_reg_debug_dispatcher_spec_"-et beáll?tva kérhet?nk más dispatcher-t. Az el?z? cikk példáiban is használt UseCommandLine a szkript?nk futtatásakor megadott parancssori paraméterek alapján d?nti el, hogy mi a teend?je:

--register: regisztrálja class-unkat, ez az alapértelmezés(korábbi cikkem példáinál ezért nem adtunk meg semmit a parancssorban)
--unregister: kiszedi a registry-b?l a beregisztrált class-unk adatait
--debug: beiktat egy dispatcher-t(a DispatcherWin32trace-t, vagy ha van _reg_debug_dispatcher_spec_, akkor az általa meghatározott dispatcher-t)

Miért fontos az el?z? folyamat ismerete? Mindaddig am?g egy regisztrált class-unk van és annak met?dusai nem akarnak COM objektumot visszadni, igazáb?l nem t?l érdekes az egész. Baj akkor van, ha van egy python objektumunk, amit szeretnénk ?gy visszadni a kliensnek, hogy az egy kezelhet? IDispatch interfészes COM objektumot lásson. Erre val? a win32com.server.util.wrap, aki megcsinálja a fenti becsomagol? eljárást. FIGYELEM: minden olyan python class-nak, amit csomagolni szeretnénk rendelkeznie kell azokkal az attributumokkal, amit a használt policy(wrap f?ggvény usePolicy argumentuma) megk?ván, de nem kellenek a regisztráci?s paraméterek ha nem akarjuk regisztrálni(pl. csak egy másik objektum met?dus h?vásain kereszt?l érhet? el). A win32com.server.util.wrap f?ggvény párja a win32com.server.util.unwrap, amivel a klienst?l visszakapott COM objektumokb?l kicsomagolhatjuk a python objektumot. Ha olyan COM objektumot pr?bálunk meg kicsomagolni, aki nem tartalmaz python objektumot(mert nem Python-ban ?rták) akkor hiba?zenetet kapunk.

DynamicPolicy használata és egyszer? példák

A DynamicPolicy a DesignatedWrapPolicy-vel ellentéttem - mint nevéb?l is sejthet? - dinamikusan futásk?zben határozza meg, hogy milyen met?dusok és attributumok láthat?ak a COM-on kereszt?l, azaz nincs a class-unknak _public_methods_, _public_attrs_ stb. attributuma. Ez a dinamikusság annyira igaz, hogy futás k?zben gyárthatunk és megsz?ntethet?nk met?dusokat, tulajdonságokat. A DynamicPolicy van annyira rendes hozzánk, hogy elintézi az IDispatch interface Invoke és GetIDsOfNames h?vásainak kezelését, nek?nk már csak nevekkel kell foglalkozni. Class-unknak a szokásos regisztráci?s attributumain k?v?l csak egyetlen k?telez? met?dusra van a _dynamic_, amiben le kell kezelni a met?dusok h?vását, az attributumok lekérdezését ill. értékadását vagy adott esetben "le kell tagadnunk azok létét".

Python kliens esetében met?dusra hivatkozás is el?sz?r tulajdonság lekérdezésként jelenik meg (_dynamic_ met?dus wFlags argumentuma) és ilyenkor pythoncom.DISP_E_MEMBERNOTFOUND exception-t generálva lehet rávenni, hogy met?dusként is pr?bálja meg. Ez azért van, mert a Python világban a met?dus is attributum. VB kliens esetén pedig met?dus h?váskor a _dynamic_ met?dus wFlags argumentuma pythoncom.DISPATCH_PROPERTYGET | pythoncom.DISPATCH_METHOD is lehet, mert a VB bizonyos helyzetekben képtelen eld?nteni melyikr?l van sz?. A pythoncom.DISPATCH_METHOD vizsgálatot el?re véve és kiegész?tve annak viszgálatával, hogy az attributum val?ban met?dus-e a kérdés megnyugtat?an kezelhet?.

A lenti példákban igyekeztem mindent kisbet?sen használni a python forrásokban ill. a kapott paramétereket kisbet?sre konvertáltam, mert pl. a VB-nek mindegy hogy kisbet? vagy nagybet?, de a Python megk?l?nb?zteti.

Az els? példa nagyon egyszer?: COM objektumunknak nincs egyetlen met?dusa sem, viszont futásid?ben korlátlan szám? ?j tulajdonságot hozhatunk létre és azok értékét lekérdezhetj?k, m?dos?thatjuk, s?t tipusukat is megváltoztathatjuk.

A példa forrása és egy teszt kliens.

Második példánk egy buta v?z objektum lesz, a H2O. Egy H2O instance allapot tulajdonsága "szilárd" vagy "folyékony" lehet(létrehozás után "folyékony"). Az allapot tulajdonság mindig lekérdezhet?, de nem lehet direktben m?dos?tani. A masolj met?dus is mindig megh?vhat? és a visszadott érték egy ?j H2O instance lesz az aktuális állapottal. A fagyjmeg és az olvadjmeg met?dusok csak a megfelel? allapot érték esetén léteznek, azaz pl. "szilárd" allapot esetében fagyjmeg h?vása "Member not found." hiba?zenetet generál.

A példa forrása és egy egyszer? kliens a teszteléshez.

COMToCorba: egy realisztikusabb példa a DynamicPolicy-ra

A DynamicPolicy használatára egy kicsit bonyolultabb, de realisztikusabb példa a COMToCorba scriptem, mellyel COM-b?l lehet Corba objektumokat elérni. Ebben a programban a unicode kezelésére is láthattok példát. Egyrészt a COM bel?l unicode-os, ezért ami bemegy az unicode-ra konvertál?dik és ?gy is j?n ki bel?le. Másrészt a Python 1.52-es verzi?jában viszont még nem volt unicode kezelés, ezért figyelni kellett például a COM-b?l j?v? stringekre ha azokat Python-ban is használni akartuk(egy str() h?vás megtette). A Python 2.0-ás verz?ja már kezeli a unicode-ot, ?gy ez a gond megsz?nt. Az omniORBpy viszont még nem kezel unicode-ot, tehát miatta(és minden nem unicode-os api használata miatt is) még mindig konvertálgatni kell.

sszegzés

Ebbe a cikkbe ennyi fért bele. Az online elérhet? dokumentáci?kon és programforrásokon k?v?l ajánlom figyelmetekbe Mark Hammond és Andy Robinson k?nyvét: Python Programming on win32(néhány dolgot én is ebb?l szipkáztam:-)). Természetesen a lenti c?memen is pr?bálkozhatsz ha végképp elakadtál.

Kiss `rpád