Problème de fonctionnement d'un fichier d'aide créé avec Html Help Work Shop [Résolu]

[Gilbert Geyer]

Bonjour,

J'ai un fichier Aide.chm créé avec Html Help Work Shop qui fonctionne correctement sous Xp, mais pas sous le Vista d'un collègue !

Est-ce-que quelqu'un s'est déjà heuté à ce même problème ?

Et si oui, existe-il une parade S.V.P ?

Cordialement et à +.

[Dr.Who]

si le probleme consiste en des erreur d'ouverture de page, de recherche qui n'aboutissent pas, le probleme existe egalement sous XP.

le fait est que le systeme de prevention d'execution des données "SPED" bloque l'execution de certaines action, notamment au seins des fichiers CHM/HLP.

il suffit de faire un clique droit sur le fichier a partir de l'explorateur, puis de choisir "propriétés"

dans les propriétés un case a coché du genre "verouiller ce fichier" est cochée. donc il suffit de la decochée pour deverouiller le fichier et pouvoir ainsi le voir fonctionner correctement. ou encore un boutton "deverouiller le fichier"

maintenant je ne peux garantir le resultat puisque les informations sur l'erreur ne sont pas plus detaillé que ça ...

[Gilbert Geyer]

Bonjour,

Merci pour ces tuyaux on va essayer votre suggestion.

Vous dites :

maintenant je ne peux garantir le resultat puisque les informations sur l'erreur ne sont pas plus detaillé que ça

... en fait, sous Vista chez mon collègue, l'aide souvre mais affiche "Navigation vers la page Web annulée" alors que sous XP tout se passe normalement.

Cordialement et à +.

[tenpigs]

Bonjour,

J'ai rencontré cette même erreur en essayant d'ouvrir un chm sur un chemin réseau... c'est causé par une règle de sécurité sur la zone intranet.
Cordialement.

[Gilbert Geyer]

Bonjour,

A Tenpigs : Merci pour cette info.

Cordialement et à +.

[Mac LAK]

Modifie ces clés de registre, normalement, ça devrait débloquer tes CHM :

Code :

1
2
3
4
5
6
7
8
9
10
11
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\HHRestrictions]
"EnableFrameNavigationInSafeMode"=dword:00000000
"MaxAllowedZone"=dword:00000001
"UrlAllowList"="\\\\;/;"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions] 
"EnableFrameNavigationInSafeMode"=dword:00000000
"MaxAllowedZone"=dword:00000001
"UrlAllowList"="\\\\;/;"

(A sauver dans un fichier .REG, puis le fusionner).

Le souci se pose en général lorsque l'on ouvre un CHM sur un disque réseau.

[Gilbert Geyer]

Bonjour,

Pour info je signale que la solution très simple préconisée par Dr.Who a très bien fonctionné sous Vista utilisé par mon collègue. Du coup nous n'avons pas essayé celle de Mac LAK.

En tous cas mille fois merci à tous.

Cordialement et à +.

[Mac LAK]

Envoyé par Gilbert Geyer

Pour info je signale que la solution très simple préconisée par Dr.Who a très bien fonctionné sous Vista utilisé par mon collègue. Du coup nous n'avons pas essayé celle de Mac LAK.

Celle de Dr. Who fonctionne "fichier par fichier", la mienne déverrouille tous les CHM inconditionnellement pour un poste donné (et est très facilement automatisable par un programme / setup).

Les deux solutions n'ont pas vraiment le même fonctionnement, donc.

[Andnotor]

J'ai fait un essai (XP) avec ton idée Mac Lak (copier/coller dans un reg), mais ça ne fonctionne pas !

J'avais aussi abordé le sujet et les chemins doivent être qualifiés. Un \\ n'est pas suffisant. Tous les fichiers du répertoire peuvent être ouverts avec file:/;

[Mac LAK]

Envoyé par Andnotor

J'ai fait un essai (XP) avec ton idée Mac Lak (copier/coller dans un reg), mais ça ne fonctionne pas !

??? J'ai fait cette manip des dizaines de fois, avec ou sans domaine, et ça fonctionne systématiquement... Il n'y a pas eu d'erreur à la fusion dans la registry ? Tu as vérifié les valeurs des clés après fusion, histoire de voir si elles ont bien été modifiées ?

Je n'ai pas "inventé" ces clés de registre, je les ai récupérées depuis une KB Microsoft il y a de ça un petit moment. De mémoire, je n'ai pas modifié un seul caractère, j'ai juste groupé deux .REG en un seul afin d'éviter les doubles manips. Normalement, tu désactives les protections pour les CHM locaux (inclus contenu actif, bien sûr) et réseau avec ça.

Après, j'utilise à 99% des CHM provenant soit de Doxygen, soit d'un projet "manuel" fait par l'IDE HHW (mise en CHM d'un site offline par exemple)... Peut-être une piste, donc.

[Andnotor]

Oui le registre est correct !

Extrait du kb:

Remarque Comme vous pouvez le voir dans l'exemple, pour activer un chemin UNC vers un dossier réseau partagé, vous devez ajouter les deux entrées suivantes :
\\productmanuals\helpfiles\;file://\\productmanuals\helpfiles

[Mac LAK]

Envoyé par Andnotor

Oui le registre est correct !

Ce n'est pas ce KB que j'avais utilisé, mais ça ne reste vraiment pas normal, tout ça... J'ai testé ce .REG avec succès sur du Windows 2000 et du XP Pro, les deux avec et sans domaine, et ça a toujours marché immédiatement sans aucune autre modification. A la limite, tu m'aurais dit que ça plantait sous Vista, admettons, mais sous XP, là, je suis stupéfait.

Je serais curieux de voir le CHM causant cette erreur, je dois dire...

[Dr.Who]

Dans le mesure du possible on ne modifiera pas le registre pour contourner le système de prévention d'exécution des données.


au moment du téléchargement et de l'ouverture d'un fichier, le SPED demande si il doit maintenir ou non la prévention d'execution sur le fichier, il suffit de décocher ou cocher la case selon XP ou Vista et à chaque fois que le SPED le demande.
Cela aura pour effet de déverrouiller le fichier définitivement ou pas.

à savoir que l'on peu propager du code malicieux via CHM/HLP. donc la modification du registre n'est pas conseillée surtout sur un poste de travail.
La manipulation sur le registre doit donc rester une solution secondaire et seulement applicable en cas de réelle nécessité et en connaissance des risques.

cela n'est pas comme si nous désactivions par le registre la génération des Fichier ouvert récemment ou le maintient d'un historique quelconque, ou une options d'affichage, de killservice ou autre.
ça oui, on pourra le faire sans risque.

mais modifier un paramètre de sécurité de la sorte reste une action risquée et on dois prendre en compte la perte du niveau de sécurité que l'action engendre.

[Mac LAK]

Envoyé par Dr.Who

mais modifier un paramètre de sécurité de la sorte reste une action risquée et on dois prendre en compte la perte du niveau de sécurité que l'action engendre.

En l'occurrence, dans mon cas personnel, c'est simplement ouvrir des docs que NOUS générons nous-même à partir de n'importe quel point du domaine, quel que soit l'emplacement de stockage.
Pour la sécurité intrinsèque du réseau, il y a les firewalls, les filtres de mail, les AV résidents, etc. : l'opération n'est donc pas si risquée que ça, dans un tel cas de figure.

[Andnotor]

Mac Lak,

J'ai essayé avec mes propres fichiers d'aide, mais aussi certains d'Office avec les mêmes problèmes !

J'ai tout de même réussi à les ouvrir correctement, mais en ajoutant la station à la liste de l'intranet local (File://station). Ce qui expliquerait ce MaxAllowedZone = 1, les autres clés étant inutiles dans ce cas .

[Mac LAK]

Envoyé par Andnotor

J'ai tout de même réussi à les ouvrir correctement, mais en ajoutant la station à la liste de l'intranet local (File://station). Ce qui expliquerait ce MaxAllowedZone = 1, les autres clés étant inutiles dans ce cas .

Ah, possible, en effet : comme je l'ai dit, je n'ai pas "inventé" ces valeurs, mais je les ai récupérées telles quelles sur le site Microsoft.
Et comme ça marchait nickel pour tous les postes que j'ai pu avoir à toucher, je ne suis pas allé plus loin !

Peux-tu reposter un .REG modifié fonctionnant pour toi, stp ? Cela pourra toujours servir...

[Andnotor]

Code :

1
2
3
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions] 
"MaxAllowedZone"=dword:00000001

Et dans les options Internet, ajouter le serveur (ou la station) à la zone Intranet local. (Sécurité, Intranet local, bouton Sites, bouton Avancé), file://server.