Problème avec IWebBrowser2 et les threads.

**Trap D** · 07/10/2008, 21h57

Bonjour

Je vous expose le problème.

J'ai créé une toolbar pour IE. Dans cette toolbar j'ai une classe qui utilise un pointeur m_pBrowser de type IWebBrowser2. Tout cela fonctionne bien, je peux naviguer comme je veux sur Internet à l'aide de ce pointeur.

Pour certaines actions je lance des threads. Au lancement du thread j'affiche une URL, et à un certain moment déclenché par un évènement, j'affiche une autre URL. Pour l'attente de cet évènement, et pour ne pas bloquer IE, je lance un deuxième thread. Je récupère bien cet évènement et je lance lance l'affichage de la seconde URL. (Vous me suivez ?).

Le problème est que je suis sorti du contexte de ma classe, j'utilise donc un pointeur externe global ext_gl_ptrMaClasse vers ma classe pour pouvoir utiliser m_pBrowser. Sous Vista ça fonctionne mais sous XP, le système me dit qu'il ne trouve pas l'URL indiquée : le ext_gl_ptrMaClasse->m_pBrowser->Navigate(bsSite, &vEmpty, &vEmpty, &vEmpty, &vEmpty); échoue avec une erreur inconnue (j'ai testé ce n'est ni E_INVALIDARG ni E_OUTOFMEMORY).

J'ai voulu mettre une méthode publique de ma classe pour lancer le thread d'attente, mais le compilo refuse avec ce message "'cast de type'*: impossible de convertir de 'overloaded-function' en 'LPTHREAD_START_ROUTINE'".

Alors voilà, je suis bloqué, est-ce du à une méconnaissance des mécanismes C++, où je n'utilise pas la bonne fonction pour lancer les thread ? (je n'utilise pas les MFC)

Si vous avez une piste je suis preneur.

Merci.

**Médinoc** · 08/10/2008, 09h31

Tu ne peux pas utiliser "comme ça" un objet COM en multithread:

La fonction CoInitializeEx() doit être appelée pour chaque thread
Un pointeur d'interface ne doit pas être passé directement d'un thread à l'autre, à moins que l'objet soit garanti free-threadé.
- Le plus simple pour marshaller un pointeur d'interface entre deux threads, c'est d'utiliser les fonctions CoMarshalInterThreadInterfaceInStream() et CoGetInterfaceAndReleaseStream() (l'objet stream retourné est, lui, garanti free-threadé, puisqu'il est fait pour être passé tel quel entre deux threads).
Si un objet est mono-threadé, tous les appels sont effectués en réalité sur le thread qui a créé l'objet (si ce thread est initialisé en mode mono-threadé). Celui-ci doit implémenter une boucle de messages.