[COM] Definir un parametre de fonction de type char

**kacedda** · 11/04/2008, 11h31

Bonjour,

Une question COM

:
J'ai crée une interface COM. Je lui ai rajoute des fonctions. Jusque la pas de problème, ca compile et ca marche.
Puis je souhaite cree une fonction qui prend un char en parametre(chose que je n'avais pas encore fait). Quelque chose comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

getChar(char* value)

Et la, ca ne compile plus, le compilo (erreur ATL)me dit qu'il ne peut instancier ma classe IMaClasse sous pretexte qu'il ne trouve pas la fonction getChar(char* value).
Alors j'ai essayé en passant par le Wizard et aussi a la main(en modifiant bien tout les fichiers(.h, .idl)). Ca ne compile pas.

Par contre si je fais getChar(long* value), la aucun soucis, ca compile sans probleme (donc pas de soucis dans mon projet je pense, j'ai checker).

D'ou la question:
As-t-on le droit de définir des parametres de types char dans les methodes/propriete d'un objet COM?

Merci de m'eclairer

**Médinoc** · 11/04/2008, 11h56

Non. Vois-tu, le type "caractère" pour COM correspond au type OLECHAR, qui depuis un moment est passé de char à wchar_t.
Ce qui fait que ironiquement, le type de variant VT_I1 ne fait plus un octet mais deux.

Mais donc, tu dois quand même pouvoir faire un getChar(OLECHAR * value).

Quant aux strings, en COM on utilise généralement des BSTR...

**kacedda** · 11/04/2008, 12h54

Ok,
Mais si je fais OLECHAR*, alors je suppose qu'a l'appel je dois aussi passer un OLECHAR et surement pas un char.

La comme je suis sur un projet perso, je suis passer par des long(pas l'habitude des types Microsoft), mais c'est cool ca me permet de decouvrir COM.

Merci à toi Médinoc

**Médinoc** · 11/04/2008, 13h34

Envoyé par kacedda

Ok,
Mais si je fais OLECHAR*, alors je suppose qu'a l'appel je dois aussi passer un OLECHAR et surement pas un char.

en effet.

La comme je suis sur un projet perso, je suis passer par des long(pas l'habitude des types Microsoft), mais c'est cool ca me permet de decouvrir COM.

Merci à toi Médinoc

Eh bien le mieux pour la portabilité quand tu fais une interface COM, c'est d'en faire une interface duale (dérivée de IDispatch) : Elle sera compatible avec les langages comme VB et les langages de script.
Par contre, il y a des limitations sur les fonctions:

Le type de retour est forcément HRESULT (mais tu peux utiliser l'attribut IDL retval sur un paramètre).
Tu es limité à certains types: short, short*, long, long*, float, float*, double, double*, CURRENCY, CURRENCY*, DATE, DATE*, BSTR, BSTR*, IDispatch*, IDispatch**, VARIANT_BOOL, VARIANT_BOOL*, VARIANT, VARIANT*, DECIMAL, DECIMAL*, __int64, __int64*, IUnknown*, IUnknown**, SAFEARRAY*, SAFEARRAY**.
Il me semble bien aussi qu'un pointeur n'es pas censé pointer vers un tableau: Ils servent uniquement au passage par référence, les tableau doivent être des SAFEARRAY.

**kacedda** · 11/04/2008, 17h45

Envoyé par Medinoc

Il me semble bien aussi qu'un pointeur n'es pas censé pointer vers un tableau: Ils servent uniquement au passage par référence, les tableau doivent être des SAFEARRAY

Ok pour les precision, mais la je sais pas trop, un pointeur et un tableau c'est sensiblement la meme chose, non? Car on a les types long* mais aussi long**, car c'est egal a (long*)*.

Par contre pour les interfaces dual, si j'ai bien compris faut modifier le idl a la main, car le wizard ne permet pas de choisir l'interface dont on herite(je trouve ca bizarre d'ailleurs).

[Edit:]Tag resolu en passant

**Médinoc** · 11/04/2008, 18h00

Il me semble que le Wizard a carrément une case à cocher "dual".

Et dans une interface duale, tu n'as pas le droit à long**, et comme je l'ai dit, un long* est censé ne pointer que sur un seul long (comme une référence C++).

Pour un tableau de long dans une interface duale, il faut écrire SAFEARRAY(long) dans l'IDL, (ce qui en C++ sera traduit par SAFEARRAY*).

**kacedda** · 11/04/2008, 18h34

Alala mais t'as raison en fait!
J'ai teste la et effectivement tu as une case a cocher (sous Visual C++ 6.0 en tout cas)!

Par contre il me laisse creer des method/property avec long* *a en paramètre

, ni erreur ni warning (creer avec le wizard):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
	interface Iaaa : IDispatch
	{
		[id(1), helpstring("method test")] HRESULT test(long* *a);
		[propget, id(2), helpstring("property test2")] HRESULT test2(long* *a, [out, retval] long *pVal);
		[propput, id(2), helpstring("property test2")] HRESULT test2(long* *a, [in] long newVal);
	};
	interface Ibbb : IUnknown
	{
		[helpstring("method test")] HRESULT test(long* *a);
		[propget, helpstring("property test2")] HRESULT test2(long* *a, [out, retval] long *pVal);
		[propput, helpstring("property test2")] HRESULT test2(long* *a, [in] long newVal);
	};

Mais il faudrait que je fasse un main pour intancier et appeler mes objets pour voir mais si ca plante...

**Médinoc** · 11/04/2008, 18h39

Et l'IDL compile ?
Ça me parait vraiment bizarre...

D'un autre côté, MIDL m'a toujours paru un peu permissif...

Si ça compile, lance le OLE/COM object viewer pour décompiler la Type Library produite, ce serait intéressant...

**kacedda** · 14/04/2008, 11h06

Salut,

Alors j'ai regarde avec le Ole viewer et apparament a la decompilation il ressort bien des long** a:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
interface Ibbb : IUnknown {
    [helpstring("method test")]
    HRESULT _stdcall test(long** a);
    [propget, helpstring("property test2")]
    HRESULT _stdcall test2(
                    long** a, 
                    [out, retval] long* pVal);
    [propput, helpstring("property test2")]
    HRESULT _stdcall test2(
                    long** a, 
                    [in] long pVal);
};

Et en passant j'ai vu un truc etrange (enfin facon de parler

):
IDispatch:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
HRESULT _stdcall GetTypeInfo(
                    [in] unsigned int itinfo, 
                    [in] unsigned long lcid, 
                    [out] void** pptinfo);
    [restricted]
    HRESULT _stdcall GetIDsOfNames(
                    [in] GUID* riid, 
                    [in] char** rgszNames, 
                    [in] unsigned int cNames, 
                    [in] unsigned long lcid, 
                    [out] long* rgdispid);

Double pointeur et variable type char, bon j'imagine que c'est normal il doit transcrire en interne mais bon ils mettent des char dans leur fonctions

.

En tout cas ca compile sans probleme mais j'ai pas teste d'appel, je testerai chez moi ce soir ou demain.

**Médinoc** · 14/04/2008, 11h27

GetTypeInfo() utilise bien des OLECHAR, et OLEVIEW les liste en tant que char car leur type est VT_I1.

De plus, il n'y a pas vraiment de problème pour utiliser long** dans une interface normale. C'est pour une interface duale (ou une dispinterface) que ça n'est pas censé marcher aussi bien.

**Médinoc** · 14/04/2008, 11h35

En fait, il semblerait que MIDL soit bizarrement tolérant, car même dans une interface duale ou une dispinterface, la fonction se retrouve dans la Type Library, y compris la version dispinterface.

Ce qui est un peu absurde, car on ne peut pas appeler une telle fonction avec IDispatch::Invoke()...

**kacedda** · 14/04/2008, 12h25

Envoyé par Médinoc

GetTypeInfo() utilise bien des OLECHAR, et OLEVIEW les liste en tant que char car leur type est VT_I1.

Bien vu, j'y avais pas pensé, super logique en fait! Mais en meme temps je trouve que ca prete a confusion, un coup sur 2 un coup sur 1

.

De plus, il n'y a pas vraiment de problème pour utiliser long** dans une interface normale. C'est pour une interface duale (ou une dispinterface) que ça n'est pas censé marcher aussi bien.

Oui j'avais aussi teste sur les deux dual et custom.

Ce qui est un peu absurde, car on ne peut pas appeler une telle fonction avec IDispatch::Invoke()...

J'avoue que je ne suis encore jamais passer par Invoke(je viens de regarde la doc) je ne vois pas l'interet direct...
Et quand tu dis que l'on ne peut pas appeler la fonction, je ne vois pas non plus pourquoi? il doit etre possible de caster les arguments passe dans l'array et j'imagine que derriere on appelle la methode d'une "maniere classique". A tester aussi...

**Médinoc** · 14/04/2008, 12h29

IDispatch::Invoke() permet d'appeler une fonction dont on ne connait pas le prototype à la compilation.

C'est surtout utilisé dans le code d'un interpréteur de script, quand on veut que le langage de script puisse utiliser des objets COM. C'est là toute l'utilité des interfaces duales ou des dispinterfaces.

**kacedda** · 16/04/2008, 14h10

Salut,

J'ai teste(enfin).
Voici les fonctions (j'ai fait un truc bateau juste pour voir si ca passe):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
STDMETHODIMP CMyTest::doTest1(long **a)
{
	(*a)[0]++;
	(*a)[1]++;
	(*a)[2]++;
 
	return S_OK;
}
 
STDMETHODIMP CMyTest::get_doTest2(long **a, long *pVal)
{
	(*a)[0]++;
	(*a)[1]++;
	(*a)[2]++;
	return S_OK;
}

Aucune difference entre propriete ou method, et aucune difference si dual ou custom.
L'appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
	long n;
	long *a = new long[3];
	a[0] = a[1] = a[2] = 0;
	pTest->doTest1(&a);
 
	pTest->get_doTest2(&a, &n);
	pTest->put_doTest2(&a, n);

Donc j'avoue qu'on peut faire mieux

, mais ca marche les valeurs du tableau sont bien incremente (check en mode pas à pas).
Mais je suis d'accord pour admettre que c'est petre pas le plus propre.

[Edit] Concernant le Invoke... ca n'a pas l'air de marcher, si je caste mon long** en long*, le invoke me renvoit une erreur, a approfondir!

[COM] Definir un parametre de fonction de type char

Visual C++

Discussions similaires

Partager

Partager