Répertoire de travail d'I.E. (HTA vs HTML)

Bonjour !

Lorsque j'exécute un script HTA, qui appelle une autre script, contenu dans
un fichier .HTML, cela lance Internet-Explorer, avec le répertoire courant,
comme répertoire de travail.

Si je lance un script directement un script en .HTML, cela lance
Internet-Explorer, mais le répertoire de travail est alors dans "Mes
Documents".

Comment puis-je paramétrer Internet-Explorer, pour qu'il utilise, comme
répertoire de travail, le répertoire courant ? Sachant qu'I.E. est appelé
implicitement, par windows, et non explicitement, par une commande.

Autre solution possible : comment, par jscript, changer le répertoire de
travail d'I.E., depuis la session en cours ?

Merci, pour toute idée de solution.

@+

Michel Claveau

"CurrentDirectory Property"

http://msdn.microsoft.com/library/en-us/script56/html/a36f684c-efef-4069-9102-21b3d1d55e9e.asp

accessible en lecture *et* en écriture.


et/ou

créer et exécuter un raccourci en spécifiant le répertoire de travail :

"WorkingDirectory Property"

http://msdn.microsoft.com/library/en-us/script56/html/cf9f2343-3fde-42aa-acd4-4037eb33bbf0.asp

accessible en lecture *et* en écriture.

Dans un cas comme dans l'autre en utilisant WScript.Shell.

Amicalement,

--
Jean - JMST
Belgium

Salut !


Merci, mais, dans mon cas, ça ne marche pas.
En fait, ça modifie le répertoire courant... de l'instance "WScript.Shell",
mais pas le répertoire courant d'I.E.

J'ai peut-être oublié de préciser quelques détails :
- il s'agit de la version Active-X d'I.E.
- cet I.E. est embarqué dans une fiche du logiciel Paradox (par
Object-PAL)
- cette fiche est elle-même ouverte depuis une autre fiche.
- l'instance d'I.E. lance un script JScript, qui en appelle un autre,
sur disque
- j'ai une application COM-serveur (Ponx), qui sert de plate-forme de
liaison entre tout ça
- Le script JScript lance des scripts Python, via Ponx
- Ponx pilote le contenu de l'instance d'I.E. via des CallBack COM ;
c'est ainsi que sont définis les objets HTML, comme les boutons, ou les
textarea.

Le problème, c'est que, dans 20 % des installations, les import Python, ou
l'ouverture de fichiers depuis JScript, utilisent un mauvais répertoire, au
lieu du répertoire de lancement (mais, dans 80 % des installs, tout est bon)

L'utilisation que tu suggères crée une instance Wscript.Shell, affecte bien
la propriété de cette instance, mais n'affecte pas le logiciel hôte.



En fait, j'ai réussi à faire tout marcher, mais en forçant le répertoire "en
dur",pour chaque couche logicielle. Cela m'oblige à gérer une installation
(mais seulement dans 20 % des cas).
Il y a moindre mal, même si j'aurais préféré une meilleure portabilité
d'emplacement.


Bonne journée


@-salutations

Michel Claveau

Bonne journée

Il faudra que je relise :-) ... mais à première vue je me demande si la
balise BASE ne serait pas salutaire (comme je crois comprendre que vous
voulez faire des inculde avec des chemins relatifs).
Je mets ci dessous un exemple de test (exécution locale, pour un autre
contexte il y a des modifications à faire).
Soit le répertoire "c:mes fichiersmon test" contenant les fichiers
"mon fichier.txt" et "mon script.js".


<!---8<--->
<!-- Exécution HTM locale ou HTA -->
<script>
repertoire='c:\mes fichiers\mon test'
new ActiveXObject('WScript.Shell')
.CurrentDirectory=repertoire
document.write('<base href='+
transformer(
new ActiveXObject('WScript.Shell')
.CurrentDirectory
)+
'/ />'
)

function transformer(quoi){
return quoi.replace(/\/g,'/').replace(/ /g,'&#32;')
}
</script>

<a id¡>TEST1</a>
<a href='mon fichier.txt'>TEST2</a>

<script>
A1.href='mon fichier.txt'
</script>

<script src='mon script.js'></script>

<script>
alert(
new ActiveXObject('Scripting.FileSystemObject')
.getFile('mon fichier.txt')
.size
)
</script>
<!---8<--->

Amicalment,

--
Jean - JMST
Belgium