La plupart des langages (de script) permettent d'appeler un serveur COM.
Exemples :
JScript new ActiveXObject("Toto.titi");
ObjectPal Open("Toto.titi")
Python win32com.client.Dispatch("Toto.titi")
VBScript WScript.CreateObject("Toto.titi")
Ruby WIN32OLE.new('Toto.titi')
etc.
Mais, il y a le cas des serveurs COM dynamiques. Ce genre de logiciel n'a
pas de fonctions/méthodes prédéfinies, à l'enregistrement. Il n'est donc pas
possible au logiciel client de connaître à l'avance les fonctions
existantes. On ne peut pas explorer le serveur.
Et alors, pour l'appel d'une fonction, je me trouve confronté à plusieurs
comportement différents :
- appel normal, avec respect de la casse dans le nom de la fonction, et
passage des paramètres en unicode (JScript, VBscript, avec une particularité
sur le wFlags) ; c'est un appel "optimiste"
- appel normal, avec respect de la casse dans le nom de la fonction, et
passage des paramètres en ANSI
- appel avec conversion des noms de fonctions en majuscules (ObjectPAL)
- appel "doublé", le client testant d'abord s'il s'agit d'une propriété,
et, en cas d'erreur, effectuant un second appel, comme fonction (Python,
dans certains cas) ; c'est un appel "pessimiste".
J'aimerais avoir confirmation de ce que j'ai donc constaté, et suis à la
recherche de quelques documentation EN FRANCAIS, sur le sujet.
Merci d'avance pour tout tuyau.
Michel Claveau
PS : AMHA, cela pourrait aussi expliquer les problèmes qu'ont certains
clients avec la fonction GetStruct d'OOo...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Barathon [MS]
Hello Michel,
Quelque chose m'échappe: si le logiciel client ne connaît pas à l'avance les fonctions offertes par un serveur COM, comment peut-il faire un appel en utilisant le nom de ces fonctions? Si tu avais un exemple concret, je comprendrais peut-être un peu mieux.
Merci, Jacques
"Do Re Mi chel La Si Do" wrote in message news:
Bonjour !
J'ai une 'tite question.
La plupart des langages (de script) permettent d'appeler un serveur COM. Exemples : JScript new ActiveXObject("Toto.titi"); ObjectPal Open("Toto.titi") Python win32com.client.Dispatch("Toto.titi") VBScript WScript.CreateObject("Toto.titi") Ruby WIN32OLE.new('Toto.titi') etc.
Mais, il y a le cas des serveurs COM dynamiques. Ce genre de logiciel n'a pas de fonctions/méthodes prédéfinies, à l'enregistrement. Il n'est donc pas possible au logiciel client de connaître à l'avance les fonctions existantes. On ne peut pas explorer le serveur.
Et alors, pour l'appel d'une fonction, je me trouve confronté à plusieurs comportement différents : - appel normal, avec respect de la casse dans le nom de la fonction, et passage des paramètres en unicode (JScript, VBscript, avec une particularité sur le wFlags) ; c'est un appel "optimiste" - appel normal, avec respect de la casse dans le nom de la fonction, et passage des paramètres en ANSI - appel avec conversion des noms de fonctions en majuscules (ObjectPAL) - appel "doublé", le client testant d'abord s'il s'agit d'une propriété, et, en cas d'erreur, effectuant un second appel, comme fonction (Python, dans certains cas) ; c'est un appel "pessimiste".
J'aimerais avoir confirmation de ce que j'ai donc constaté, et suis à la recherche de quelques documentation EN FRANCAIS, sur le sujet.
Merci d'avance pour tout tuyau.
Michel Claveau
PS : AMHA, cela pourrait aussi expliquer les problèmes qu'ont certains clients avec la fonction GetStruct d'OOo...
Hello Michel,
Quelque chose m'échappe: si le logiciel client ne connaît pas à l'avance les
fonctions offertes par un serveur COM, comment peut-il faire un appel en
utilisant le nom de ces fonctions? Si tu avais un exemple concret, je
comprendrais peut-être un peu mieux.
Merci,
Jacques
"Do Re Mi chel La Si Do" <enleverlesO.OmcO@OmclaveauO.com> wrote in message
news:uTNM8YS4FHA.3948@TK2MSFTNGP09.phx.gbl...
Bonjour !
J'ai une 'tite question.
La plupart des langages (de script) permettent d'appeler un serveur COM.
Exemples :
JScript new ActiveXObject("Toto.titi");
ObjectPal Open("Toto.titi")
Python win32com.client.Dispatch("Toto.titi")
VBScript WScript.CreateObject("Toto.titi")
Ruby WIN32OLE.new('Toto.titi')
etc.
Mais, il y a le cas des serveurs COM dynamiques. Ce genre de logiciel n'a
pas de fonctions/méthodes prédéfinies, à l'enregistrement. Il n'est donc
pas possible au logiciel client de connaître à l'avance les fonctions
existantes. On ne peut pas explorer le serveur.
Et alors, pour l'appel d'une fonction, je me trouve confronté à plusieurs
comportement différents :
- appel normal, avec respect de la casse dans le nom de la fonction, et
passage des paramètres en unicode (JScript, VBscript, avec une
particularité sur le wFlags) ; c'est un appel "optimiste"
- appel normal, avec respect de la casse dans le nom de la fonction, et
passage des paramètres en ANSI
- appel avec conversion des noms de fonctions en majuscules (ObjectPAL)
- appel "doublé", le client testant d'abord s'il s'agit d'une
propriété, et, en cas d'erreur, effectuant un second appel, comme fonction
(Python, dans certains cas) ; c'est un appel "pessimiste".
J'aimerais avoir confirmation de ce que j'ai donc constaté, et suis à la
recherche de quelques documentation EN FRANCAIS, sur le sujet.
Merci d'avance pour tout tuyau.
Michel Claveau
PS : AMHA, cela pourrait aussi expliquer les problèmes qu'ont certains
clients avec la fonction GetStruct d'OOo...
Quelque chose m'échappe: si le logiciel client ne connaît pas à l'avance les fonctions offertes par un serveur COM, comment peut-il faire un appel en utilisant le nom de ces fonctions? Si tu avais un exemple concret, je comprendrais peut-être un peu mieux.
Merci, Jacques
"Do Re Mi chel La Si Do" wrote in message news:
Bonjour !
J'ai une 'tite question.
La plupart des langages (de script) permettent d'appeler un serveur COM. Exemples : JScript new ActiveXObject("Toto.titi"); ObjectPal Open("Toto.titi") Python win32com.client.Dispatch("Toto.titi") VBScript WScript.CreateObject("Toto.titi") Ruby WIN32OLE.new('Toto.titi') etc.
Mais, il y a le cas des serveurs COM dynamiques. Ce genre de logiciel n'a pas de fonctions/méthodes prédéfinies, à l'enregistrement. Il n'est donc pas possible au logiciel client de connaître à l'avance les fonctions existantes. On ne peut pas explorer le serveur.
Et alors, pour l'appel d'une fonction, je me trouve confronté à plusieurs comportement différents : - appel normal, avec respect de la casse dans le nom de la fonction, et passage des paramètres en unicode (JScript, VBscript, avec une particularité sur le wFlags) ; c'est un appel "optimiste" - appel normal, avec respect de la casse dans le nom de la fonction, et passage des paramètres en ANSI - appel avec conversion des noms de fonctions en majuscules (ObjectPAL) - appel "doublé", le client testant d'abord s'il s'agit d'une propriété, et, en cas d'erreur, effectuant un second appel, comme fonction (Python, dans certains cas) ; c'est un appel "pessimiste".
J'aimerais avoir confirmation de ce que j'ai donc constaté, et suis à la recherche de quelques documentation EN FRANCAIS, sur le sujet.
Merci d'avance pour tout tuyau.
Michel Claveau
PS : AMHA, cela pourrait aussi expliquer les problèmes qu'ont certains clients avec la fonction GetStruct d'OOo...
Do Re Mi chel La Si Do
Re
Que les fonctions ne soient pas exposées tant que le module n'est pas chargé, je ne vois pas en quoi ça pose problème pour un langage de scripting
Le truc, c'est que, selon qu'un serveur COM expose ses méthodes/fonctions/propriétés (serveurs statiques, cas courants, comme Word, Excel, WSscript, etc.), ou ne les expose pas (serveurs dynamiques), l'implémentation n'est pas la même, et le comportement de Windows est différent.
En pratique, comme tu l'as dit, on découvre à l'usage. les petits problèmes. Heureusement que je peux modifier le code de PONX, pour l'adapter aux différents cas. Ma peur, c'est que des clients tombent sur des choses que je n'avais pas vues.
Pour l'histoire du double accès : PONX est un serveur COM, avec deux points d'entrée : un statique, avec des fonctions prédéfinies, l'autre dynamique, donnant l'accès à toutes les fonctions, et toutes les propriétés, internes. Mais il s'agit bien du même serveur. Ce double accès permet de faire pas mal de choses.
@-salutations
Michel Claveau
Re
Que les fonctions ne soient pas exposées tant que le module n'est pas
chargé, je ne vois pas en quoi ça pose problème pour un langage de
scripting
Le truc, c'est que, selon qu'un serveur COM expose ses
méthodes/fonctions/propriétés (serveurs statiques, cas courants, comme Word,
Excel, WSscript, etc.), ou ne les expose pas (serveurs dynamiques),
l'implémentation n'est pas la même, et le comportement de Windows est
différent.
En pratique, comme tu l'as dit, on découvre à l'usage. les petits problèmes.
Heureusement que je peux modifier le code de PONX, pour l'adapter aux
différents cas. Ma peur, c'est que des clients tombent sur des choses que je
n'avais pas vues.
Pour l'histoire du double accès : PONX est un serveur COM, avec deux points
d'entrée : un statique, avec des fonctions prédéfinies, l'autre dynamique,
donnant l'accès à toutes les fonctions, et toutes les propriétés, internes.
Mais il s'agit bien du même serveur.
Ce double accès permet de faire pas mal de choses.
Que les fonctions ne soient pas exposées tant que le module n'est pas chargé, je ne vois pas en quoi ça pose problème pour un langage de scripting
Le truc, c'est que, selon qu'un serveur COM expose ses méthodes/fonctions/propriétés (serveurs statiques, cas courants, comme Word, Excel, WSscript, etc.), ou ne les expose pas (serveurs dynamiques), l'implémentation n'est pas la même, et le comportement de Windows est différent.
En pratique, comme tu l'as dit, on découvre à l'usage. les petits problèmes. Heureusement que je peux modifier le code de PONX, pour l'adapter aux différents cas. Ma peur, c'est que des clients tombent sur des choses que je n'avais pas vues.
Pour l'histoire du double accès : PONX est un serveur COM, avec deux points d'entrée : un statique, avec des fonctions prédéfinies, l'autre dynamique, donnant l'accès à toutes les fonctions, et toutes les propriétés, internes. Mais il s'agit bien du même serveur. Ce double accès permet de faire pas mal de choses.
