Forums : XPCom

j'ai résolu ce problème en passant au composant XPCOM non le pas le textbox lui-même, mais son membre inputField, qui est un composant nsIDOMHTMLInputElement, dont l'attribut value, lui, reflète le contenu du textbox associé.

Tout à fait. <Textbox> est en fait XBL (comme beaucoup d'élement XUL d'ailleurs), contenant un <input> html. Voir dans toolkit.jar pour voir comment il est constitué.

Seulement, lorsque je crée un textbox en C++, avec un CreateElement d'un nsIDOMDocument, et bien je ne récupère à nouveau qu'un nsIDOMElement.

Normal. Comme je l'ai dit, <textbox> est un xbl. Donc tant qu'il n'a pas été intégré dans le document, le style associé à la balise <textbox> ne sera pas appliqué, donc le binding ne sera pas appliqué, donc tu n'aura pas accés aux propriétés définies par le xbl.

Tu comprendra donc qu'il n'y a pas de cast à faire. Il suffit en théorie d'incorporer ton element dans le document.

Problème : une fois la balise incorporée dans le document, il y a un temps de latence pour l'application des styles. En effet, ils sont appliqués en parallèle de ton traitement. Donc une fois la fonction appendChild effectué, le binding n'est pas encore appliqué à ta balise (le temps que Gecko trouve les propriétés de style appliquées à ta balise, et comme ici il s'agit d'appliquer un xbl, il faut le temp que le XBL soit chargé, puis appliqué etc...)

Bref, donc, il faut pouvoir détecter quand est ce que le binding est appliqué pour pouvoir manipuler les propriétés xbl de textbox. (je crois qu'il y a un xblmanager ou un truc comme ça).

Maintenant, si, lors de la création de textbox, il s'agit juste de lui appliquer une valeur, il suffit juste de lui mettre l'attribut value comme il faut.

Merci pour ces explications ; je comprend mieux maintenant ce que m'affiche le 'DOM Inspector', surtout aprés avoir consulté le contenu du 'toolkit.jar'. Malheureusement, cela ne résout pas mon problème, qui est de récupèrer, en C++, la valeur qu'un utilisateur a saisie dans un 'textbox'. J'ai beau passer en revue tous les fichiers du répertoire 'include' du SDK Gecko, je ne vois pas comment atteindre cette valeur en partant du 'nsIDOMElement *' de ce 'textbox' (le 'cast' que j'ai mentionné dans mon premier message ne fonctionnant pas). Il manque une fonction qui fasse le lien entre ce 'nsIDOMElement *' et le 'nsIDOMHTMLInputElement *' rattaché, fonctionnalité qui existe en Javascript (membre 'inputField'), mais pas dans le SDK Gecko ...

Les élements définis dans le xbl sont des éléments "anonymous". Tu ne peux pas y accéder via les méthodes DOM classique. Pour accéder au contenu anonyme d'un élement, il faut que tu passe par les méthodes définies par l'interface nsIDOMDocumentXbl (donc faire un QI sur le document). Bien sûr, il faut que tu sois sûr que le binding soit appliqué au moment où tu récupères les élements anonymes.

Si cette interface n'est pas dispo dans le SDK, (ce qui est possible, vu qu'elle n'est pas "frozen"), compile tes composants avec les sources de Firefox. D'ailleurs, peu de gens utilisent le SDK de gecko pour développer leurs composants. Le SDK est surtout fait pour ceux qui embarquent Gecko dans leurs logiciels.

En effet, pas de nsIDOMDocumentXbl dans le SDK.

Utiliser les sources nécessite de recompiler le SDK, n'est-ce pas ? Devant réaliser un composant multi-plateforme, je préfère, pour l'instant, m'en tenir au SDK précompilé, histoire de ne pas me compliquer la tâche. En tout cas, merci pour toutes ces infos.

Soit dit en passant, pour compléter ce que j'ai écrit dans un de mes précédents commentaires, lorsque, pour un textbox, on met l'attribut multirow à true, le champ inputField ne pointe plus sur un nsIDOMHTMLInputElement, mais sur un nsIDOMHTMLTextAreaElement ...

Utiliser les sources nécessite de recompiler le SDK, n'est-ce pas ?

C'est assez compliqué de recompiler le SDK avec ce que l'on veut dedans. Franchement, le plus facile est de récupérer les sources de firefox, de le compiler, et de compiler ton composant avec. Sinon tu ne pourra pas faire ce que tu veux.

Utiliser ou pas le SDK ne rendra pas plus ou pas moins ton composant multiplateforme.

lorsque, pour un textbox, on met l'attribut multirow à true, le champ inputField ne pointe plus sur un nsIDOMHTMLInputElement, mais sur un nsIDOMHTMLTextAreaElement ...

Oui normal, ce n'est plus le même xbl qui est attaché. (voir le fichier xul.css dans toolkit.jar)

C'est assez compliqué de recompiler le SDK avec ce que l'on veut dedans. Franchement, le plus facile est de récupérer les sources de firefox, de le compiler, et de compiler ton composant avec. Sinon tu ne pourra pas faire ce que tu veux.

Tu veux dire que que, en recompilant Mozilla (je préfère utiliser Mozilla pour le développement, pour éviter les conflits avec Firefox, que j'utilise comme navigateur WEB), il me génèrera aussi xpidl.exe ainsi que les bibliothèques qui vont bien (nspr4.lib, plc4.lib, ...) , et ce, sans avoir à modifier les options de compilation données par défaut ?

Utiliser ou pas le SDK ne rendra pas plus ou pas moins ton composant multiplateforme.

Non, bien sûr ! Mais devant porter mon composant sur une plateforme que je ne connais pas bien (je pense au Mac, en l'occurrence), je préfère procèder par étape. Déjà essayer (et réussir) à créer mon composant avec le SDK, vu qu'il existe précompilé pour Mac, et alors seulement compiler Mozilla (et cela vaut aussi pour Windows, que je connais pourtant mieux).

il me génèrera aussi xpidl.exe ainsi que les bibliothèques qui vont bien (nspr4.lib, plc4.lib, ...) , et ce, sans avoir à modifier les options de compilation données par défaut ?

oui. tu retrouveras ça dans dist/sdk/.

Tu as donc non seulement les outils du sdk, mais aussi tout les idl et fichiers d'en-tête des composants que tu trouves dans firefox.

Attention, si tu fais un composant déstiné à Firefox, compile Firefox et non Mozilla car tu n'auras pas forcément les mêmes idl et fichiers d'entete. Du coup ton composant risque de ne pas fonctionner car il ne trouve pas un composant dans firefox alors qu'il est dispo dans Mozilla et vice-versa.

Et puis au cas où tu fera des fichiers XUL, faut savoir également que la suite Mozilla n'utilise pas le même toolkit que Firefox/Thunderbird, donc tu n'as pas le même jeu de balises XUL (il y a des différences).

Pour ce qui est de ta problèmatique de plateforme : si tu suis les recommandations dans la façon de coder ton composant, ne t'inquiète pas, il fonctionnera à l'identique sur chaque plateforme.

La seule différence va être dans la configuration de ton environnement de compilation. Or, que ce soit avec le sdk précompilé ou un mozilla à compiler, tu va te retrouver avec les mêmes embêtements (si tu en as).

Attention, si tu fais un composant déstiné à Firefox, compile Firefox et non Mozilla car tu n'auras pas forcément les mêmes idl et fichiers d'entete. Du coup ton composant risque de ne pas fonctionner car il ne trouve pas un composant dans firefox alors qu'il est dispo dans Mozilla et vice-versa.


Et puis au cas où tu fera des fichiers XUL, faut savoir également que la suite Mozilla n'utilise pas le même toolkit que Firefox/Thunderbird, donc tu n'as pas le même jeu de balises XUL (il y a des différences).

En fait, mon composant est destiné à xulrunner. Je ne me sers de Mozilla que pour le développement, pour pouvoir disposer d'outils comme la console Javascript, ou encore le 'DOM Inspector' ...

A propos, qu'est-ce qui est le plus proche de xulrunner ? Mozilla ou Firefox ?

Pour ce qui est de ta problèmatique de plateforme : si tu suis les recommandations dans la façon de coder ton composant, ne t'inquiète pas, il fonctionnera à l'identique sur chaque plateforme.

C'est bien pour cela que j'ai choisi Gecko !

En fait, mon composant est destiné à xulrunner.

Donc utilise les sources de XulRunner pour compiler ton composant (et non de mozilla).

A propos, qu'est-ce qui est le plus proche de xulrunner ? Mozilla ou Firefox ?

xulrunner 1.8 = gecko 1.8. Firefox 1.5 = gecko 1.8. Donc c'est Firefox. (Mozilla 1.7 = gecko 1.7, seamonkey = gecko 1.8 mais avec le vieux toolkit de mozilla 1.7)