AfxSetResourceHandle ( ) help

Bonjour,
Mon programme multilingue charge au démarrage une dll linguistique contenant un ensemble de resources Neutral (commune à toutes les langues, contenant les boites de dialogues) et d'autre part des StringTables localisées.
J'utilise pour charger cette DLL la méthode décrite par Farscape:
http://c.developpez.com/faq/vc/?page...gMultiLanguage
Cela fonctionne parfaitement sur mon PC et semble t'il sur tout les PCs contenant l'environnement de développement.
Par contre en distribution c'est autre chose mon appli plante...
Je pense avoir +- localisé le problème mais je ne sait pas vraiment comment le résoudre. Les resources Neutral contiennent des objets ActiveX (Spread), j'ai l'impression que ce sont ces objets qui ne passent pas.
J'ai un message d'erreur au lancement de mon appli "An unsupported operation was attempted "
Si j'enlève cette dll linguistique mon prg tourne avec les resources originales sans problème.
Avez-vous une idée pour moi?

salut,
ces activex sont distribués et enregistrés sur les postes ?

Oui les activeX sont bien enregistrés.
Si je ne charge pas la DLL linguistique au démarrage, je tourne donc sur les resources originales l'appli démarrare correctement

J'ai fait tourner la version 'Debug' sur une machine qui me pose le problème j'ai plusieurs assertions au démarrage: la première f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp line 926
elle se produit bien après avoir charger la dll au moment ou l'appli interprète la 'command line'

Code:

---

1 2 3

if (!ProcessShellCommand(cmdInfo)) return FALSE; avec cmdInfo => cmdInfo.m_nShellCommand = CCommandLineInfo::FileNew;

---

tu as distribué les MFC (7 d'après ce que je vois ) avec ton application ? (vcredist )

oui les Mfc sont linkée statiquement avec l'appli, les mises à jour se font via le net c'est plus pratique pour moi. Ce qui m'étonne c'est que je suis sur VS2005 (mfc 8 non!)

si ça fonctionne sur un poste de dev ,
c'est que le probléme tourne autour de la distribution d'un module ocx ,dll etc..
ou de son enregistrement, vérifie bien que les ocx soient correctement enregistrés ça ne serait pas la première fois que ça arrive...

Cela tourne effectivement autour d'un OCX (FP Spread). Il est bien enregistré sur la machine de test (l'application tourne sans la dll linguistique).

La difference entre les resources de la Dll linguistique et les resources de l'appli se situe uniquement au niveau de la string table.
La dll linguistique contient cet ocx dans les resources Neutral avec un CLSID identique à celui qui se trouve dans les resources de l'application.
Le fait de charger d'abord les resources principales et de venir les surcharger ne peut il pas provoquer un problème de licence?
Ne peut-on pas au démarrage de l'appli empècher le chargement des resources principales?

ton ocx ne serait pas en dll MFC ?
et dans ce cas attention aux dll MFC ...

Que veux-tu dire?
EN tous les cas cela semble bien être un problème d'enregistrement. Si je désenregistre (regsvr32 /u) mon ocx et que je lance mon appli sans resources linguistiques, l' ASSERT est le même, comme si l'utilisation de AfxSetResourceHandle() venait provoquer un probleme au niveau de l'enregistrment

que si c'est un activex MFC ,il y a de fortes chances qu'il utilise les DLL MFC ...

Ben oui...:aie:
Je ne pense pas que le problème actuel vienne de là, l'appli tourne sans la dll linguistique. Mais effectivement c'est certainement quelque chose à fixer.

J'ai une réponse de FarPoint, il semble que l'enregistrement de leur composant ne soit pas possible en dll, ou en tous les cas peut provoquer le type de probleme que je rencontre.

Existe t'il une possiblité d'avoir une partie des resources en dehors de l'appli?
Je m'explique: je garde les resources neutral dans le fichier RC de l'application (ces resources contiennent les composants OCX) et tout ce qui est localisé (Menu, StringTable,...) dans un fichier de resource externe type dll?

je ne comprends pas cette réponse ,
tu n'as pas besoin d'enregistrer la dll de ressources qui contient l'activex.
l'activex doit être enregistré.
la dll est lue et attachée au départ de l'application.
je te rappel que tu disais que ça fonctionne sur ton poste de développement...

Un extrait du message de FPSpread

Citation:

---

If the hwndCtrl is not valid, then creation of the control from the dialog template failed. This could be due to either the control not being registered or a license exception. It is probably a license exception since you say that you have explicitly registered the control.

The dialog editor in Visual Studio will use the licenseing interfaces implemented by the control to verify that your machine is licensed to use the control in design mode, and it will save the state of the control into the resources for you, along with the license key needed to create the control at run-time. But MFC/ATL will not use that license key to create the control if the dialog resource is loaded from a dll, because then anyone could get around the license that way. It will only create the control using the embedded license key if the dialog resource is loaded from the application EXE.

---

Résolu
J'ai simplement créé et placé les composants spread dynamiquement au lieu de les placer dans le fichier de resource.

Merci Farscape pour ton aide