Suite =E0 l'achat d'un nouvel ordinateur (HP Pavilion), je fus surpris
d'y d=E9couvrir une version de Python pr=E9install=E9e par d=E9faut sous
Windows. Certes, il s'agit de la version 2.2, mais c'est d=E9j=E0 =E7a.
Une br=E8ve recherche me montre que les logiciels Cyberlink Power
Cinema et HP DVD Play contiennent tous deux les fichiers pythopn24.dll
et python24.zip (via Freeze ?).
De plus, comme j'ai install=E9 OpenOffice.org 2 (qui contient Python
2=2E3.4) et Python 2.5, je me retrouve au total avec pas moins de 4
versions diff=E9rentes de Python diff=E9rentes sur un m=EAme pc !
Je précise qu'il s'agit d'un code "brut", non épuré. Il y a des morceaux de code qui ne fonctionnent pas, bien qu'ils soient conformes aux spécifs ; d'ailleurs, ça fonctionne en VBscript, mais pas en Python (on tombe sur des bugs connus de OOo).
-- @-salutations
Michel Claveau
Ben en fait je voualis aider ;-)
J'ai le boucun de Mark Hammond et n'ai pas eu de problème à faire mes objects COM en Python ... apparement ton code fait l'inverse.
hg
Michel Claveau wrote:
Re !
Je précise qu'il s'agit d'un code "brut", non épuré.
Il y a des morceaux de code qui ne fonctionnent pas, bien qu'ils soient
conformes aux spécifs ; d'ailleurs, ça fonctionne en VBscript, mais
pas en Python (on tombe sur des bugs connus de OOo).
--
@-salutations
Michel Claveau
Ben en fait je voualis aider ;-)
J'ai le boucun de Mark Hammond et n'ai pas eu de problème à faire mes
objects COM en Python ... apparement ton code fait l'inverse.
Je précise qu'il s'agit d'un code "brut", non épuré. Il y a des morceaux de code qui ne fonctionnent pas, bien qu'ils soient conformes aux spécifs ; d'ailleurs, ça fonctionne en VBscript, mais pas en Python (on tombe sur des bugs connus de OOo).
-- @-salutations
Michel Claveau
Ben en fait je voualis aider ;-)
J'ai le boucun de Mark Hammond et n'ai pas eu de problème à faire mes objects COM en Python ... apparement ton code fait l'inverse.
hg
Michel Claveau
Bonsoir !
Côté serveur COM, j'ai un (gros) logiciel en Python, qui exploite beaucoup de fonctionnalités de PyWin32, y compris l'aspect serveur COM dynamique (avec des fonctions (publiques) qui peuvent ne pas exister au moment du lancement du logiciel.
En plus, comme j'ai intégré les appels à rubyscript, il est possible d'exposer, via Python, des fonctions publiques qui sont en pratique des fonctions Ruby (chose que Ruby ne sait pas faire).
Et ce serveur COM est lui-même capable de se comporter comme client COM, pour d'autres serveurs, tels que les MS-Agents (synthèse vocale), AutoIt-X, (pilotage de windows), GraphWiz (génération de graphes), IE (tecommande naviguation Internet), etc. etc.
Par contre, là où je sèche, c'est pour gérer les évènements COM (surtout côté serveur). Mais, bon, ce n'est pas de première urgence.
-- @-salutations
Michel Claveau
Bonsoir !
Côté serveur COM, j'ai un (gros) logiciel en Python, qui exploite
beaucoup de fonctionnalités de PyWin32, y compris l'aspect serveur COM
dynamique (avec des fonctions (publiques) qui peuvent ne pas exister au
moment du lancement du logiciel.
En plus, comme j'ai intégré les appels à rubyscript, il est possible
d'exposer, via Python, des fonctions publiques qui sont en pratique des
fonctions Ruby (chose que Ruby ne sait pas faire).
Et ce serveur COM est lui-même capable de se comporter comme client
COM, pour d'autres serveurs, tels que les MS-Agents (synthèse vocale),
AutoIt-X, (pilotage de windows), GraphWiz (génération de graphes), IE
(tecommande naviguation Internet), etc. etc.
Par contre, là où je sèche, c'est pour gérer les évènements COM
(surtout côté serveur). Mais, bon, ce n'est pas de première urgence.
Côté serveur COM, j'ai un (gros) logiciel en Python, qui exploite beaucoup de fonctionnalités de PyWin32, y compris l'aspect serveur COM dynamique (avec des fonctions (publiques) qui peuvent ne pas exister au moment du lancement du logiciel.
En plus, comme j'ai intégré les appels à rubyscript, il est possible d'exposer, via Python, des fonctions publiques qui sont en pratique des fonctions Ruby (chose que Ruby ne sait pas faire).
Et ce serveur COM est lui-même capable de se comporter comme client COM, pour d'autres serveurs, tels que les MS-Agents (synthèse vocale), AutoIt-X, (pilotage de windows), GraphWiz (génération de graphes), IE (tecommande naviguation Internet), etc. etc.
Par contre, là où je sèche, c'est pour gérer les évènements COM (surtout côté serveur). Mais, bon, ce n'est pas de première urgence.
-- @-salutations
Michel Claveau
Amaury Forgeot d'Arc
En fait, pour OOo, j'aurais plutôt aimé pouvoir utiliser les fonctions "client COM" de Python+Pywin.
Alors ma réponse numéro 2 peut s'appliquer: il est possible de recompiler pywin32, de telle manière qu'il soit possible de l'utiliser sans installation particulière: on le met dans le répertoire lib/site-packages de OOo, et même n'importe où si on modifie sys.path!
C'est ce que nous avons fait pour notre application, ce qui nous a permis d'accéder facilement à des composants COM du genre Crystal Reports...
Si je me souviens bien, il suffit de modifier le code source de pywin32 comme ceci: - Modifier le projet Visual Studio, pour qu'il génère des fichiers nommés pythoncom.dll et pywintypes.dll (sans le numéro de version de Python), et supprimer la copie vers %windir%System32. - Dans pythonwinwin32cmdui.cpp, simplifier la drôle de boucle qui teste tous les noms de "pythoncom15.dll" à "pythoncom40.dll" - Supprimer le fichier win32/lib/pywintypes.py
Puis il faut recompiler le tout avec le même compilateur que celui qui a servi pour OOo (pour la version 2.0 que j'ai chez moi, et qui intègre python2.3.4, il faut VC6) (Note: il vaut mieux essayer d'utiliser un Platform SDK plus récent que celui de VC6 qui est vraiment trop vieux)
Il reste à construire la "distribution", le répertoire qu'il suffit de poser quelque part. Je me souviens l'avoir fait à la main sans trop de peine.
Je poste ceci, mais c'est plus pour ne pas oublier, et pour montrer que pywin32 est vraiment un module complexe. Bravo à l'auteur (Mark Hammond) quand même...
-- Amaury
En fait, pour OOo, j'aurais plutôt aimé pouvoir utiliser les fonctions
"client COM" de Python+Pywin.
Alors ma réponse numéro 2 peut s'appliquer: il est possible de
recompiler pywin32, de telle manière qu'il soit possible de l'utiliser
sans installation particulière: on le met dans le répertoire
lib/site-packages de OOo, et même n'importe où si on modifie sys.path!
C'est ce que nous avons fait pour notre application, ce qui nous a
permis d'accéder facilement à des composants COM du genre Crystal Reports...
Si je me souviens bien, il suffit de modifier le code source de pywin32
comme ceci:
- Modifier le projet Visual Studio, pour qu'il génère des fichiers
nommés pythoncom.dll et pywintypes.dll (sans le numéro de version de
Python), et supprimer la copie vers %windir%System32.
- Dans pythonwinwin32cmdui.cpp, simplifier la drôle de boucle qui teste
tous les noms de "pythoncom15.dll" à "pythoncom40.dll"
- Supprimer le fichier win32/lib/pywintypes.py
Puis il faut recompiler le tout avec le même compilateur que celui qui a
servi pour OOo (pour la version 2.0 que j'ai chez moi, et qui intègre
python2.3.4, il faut VC6) (Note: il vaut mieux essayer d'utiliser un
Platform SDK plus récent que celui de VC6 qui est vraiment trop vieux)
Il reste à construire la "distribution", le répertoire qu'il suffit de
poser quelque part. Je me souviens l'avoir fait à la main sans trop de
peine.
Je poste ceci, mais c'est plus pour ne pas oublier, et pour montrer que
pywin32 est vraiment un module complexe. Bravo à l'auteur (Mark Hammond)
quand même...
En fait, pour OOo, j'aurais plutôt aimé pouvoir utiliser les fonctions "client COM" de Python+Pywin.
Alors ma réponse numéro 2 peut s'appliquer: il est possible de recompiler pywin32, de telle manière qu'il soit possible de l'utiliser sans installation particulière: on le met dans le répertoire lib/site-packages de OOo, et même n'importe où si on modifie sys.path!
C'est ce que nous avons fait pour notre application, ce qui nous a permis d'accéder facilement à des composants COM du genre Crystal Reports...
Si je me souviens bien, il suffit de modifier le code source de pywin32 comme ceci: - Modifier le projet Visual Studio, pour qu'il génère des fichiers nommés pythoncom.dll et pywintypes.dll (sans le numéro de version de Python), et supprimer la copie vers %windir%System32. - Dans pythonwinwin32cmdui.cpp, simplifier la drôle de boucle qui teste tous les noms de "pythoncom15.dll" à "pythoncom40.dll" - Supprimer le fichier win32/lib/pywintypes.py
Puis il faut recompiler le tout avec le même compilateur que celui qui a servi pour OOo (pour la version 2.0 que j'ai chez moi, et qui intègre python2.3.4, il faut VC6) (Note: il vaut mieux essayer d'utiliser un Platform SDK plus récent que celui de VC6 qui est vraiment trop vieux)
Il reste à construire la "distribution", le répertoire qu'il suffit de poser quelque part. Je me souviens l'avoir fait à la main sans trop de peine.
Je poste ceci, mais c'est plus pour ne pas oublier, et pour montrer que pywin32 est vraiment un module complexe. Bravo à l'auteur (Mark Hammond) quand même...
