Bonjour,
Avec powershell, en gwmi.
Comment afficher l'URL d'une page de mon browser IE ?
est-ce avec win32_process ?
ou une autre classe ?
Merci d'avance,
Robby.
Bon à savoir. Je serais curieux de voir quelle API est utilisée dans la cuisine de PyWin32, parce que la méthode .Net [System.Runtime.InteropServices.Marshal]::GetActiveObject() qui marche très bien avec d'autres objets (notamment les applis Office) ne marche pas avec Internet Explorer... Dommage.
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent. Une solution de contournement consiste à parcourir la collection Windows de l'objet Shell.Application. La function VBScript ci-dessous retourne la première instance Internet Explorer en cours d'exécution.
Function GetActiveIEObject ()
Set GetActiveIEObject=Nothing Set oApp=CreateObject("Shell.Application") For Each oWindow In oApp.Windows() If InStr(oWindow.FullName,"Internet") Then Set GetActiveIEObject=oWindow Exit For End If Next
End Function
' on se raccroche à une instance Internet Explorer en cours d'exécution Set oIE=GetActiveIEObject() oIE.Visibleúlse
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Bonjour,
Bon à savoir. Je serais curieux de voir quelle API est utilisée dans la
cuisine de PyWin32, parce que la méthode .Net
[System.Runtime.InteropServices.Marshal]::GetActiveObject() qui marche très
bien avec d'autres objets (notamment les applis Office) ne marche pas avec
Internet Explorer... Dommage.
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution
dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject
(VBScript) ou GetActiveObject (.Net) échouent. Une solution de contournement
consiste à parcourir la collection Windows de l'objet Shell.Application. La
function VBScript ci-dessous retourne la première instance Internet Explorer
en cours d'exécution.
Function GetActiveIEObject ()
Set GetActiveIEObject=Nothing
Set oApp=CreateObject("Shell.Application")
For Each oWindow In oApp.Windows()
If InStr(oWindow.FullName,"Internet") Then
Set GetActiveIEObject=oWindow
Exit For
End If
Next
End Function
' on se raccroche à une instance Internet Explorer en cours d'exécution
Set oIE=GetActiveIEObject()
oIE.Visibleúlse
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Bon à savoir. Je serais curieux de voir quelle API est utilisée dans la cuisine de PyWin32, parce que la méthode .Net [System.Runtime.InteropServices.Marshal]::GetActiveObject() qui marche très bien avec d'autres objets (notamment les applis Office) ne marche pas avec Internet Explorer... Dommage.
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent. Une solution de contournement consiste à parcourir la collection Windows de l'objet Shell.Application. La function VBScript ci-dessous retourne la première instance Internet Explorer en cours d'exécution.
Function GetActiveIEObject ()
Set GetActiveIEObject=Nothing Set oApp=CreateObject("Shell.Application") For Each oWindow In oApp.Windows() If InStr(oWindow.FullName,"Internet") Then Set GetActiveIEObject=oWindow Exit For End If Next
End Function
' on se raccroche à une instance Internet Explorer en cours d'exécution Set oIE=GetActiveIEObject() oIE.Visibleúlse
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Jacques Barathon [MS]
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:%
Re !
GetActiveObject() ... ne marche pas avec Internet Explorer
En fait, j'avais déjà remarque des limitations (volontaires) dans le pilotage de certains objets COM, dont Internet-Explorer.
Tu es sûr que la limitation est volontaire? Tu as des infos précises là dessus? Je m'apprétais à remonter le bug, mais si c'est pour me faire répondre que c'est "by design", je vais éviter... :-)
Jacques
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com>
wrote in message news:%23lE0Z98mIHA.2396@TK2MSFTNGP02.phx.gbl...
Re !
GetActiveObject() ... ne marche pas avec Internet Explorer
En fait, j'avais déjà remarque des limitations (volontaires) dans le
pilotage de certains objets COM, dont Internet-Explorer.
Tu es sûr que la limitation est volontaire? Tu as des infos précises là
dessus? Je m'apprétais à remonter le bug, mais si c'est pour me faire
répondre que c'est "by design", je vais éviter... :-)
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:%
Re !
GetActiveObject() ... ne marche pas avec Internet Explorer
En fait, j'avais déjà remarque des limitations (volontaires) dans le pilotage de certains objets COM, dont Internet-Explorer.
Tu es sûr que la limitation est volontaire? Tu as des infos précises là dessus? Je m'apprétais à remonter le bug, mais si c'est pour me faire répondre que c'est "by design", je vais éviter... :-)
Jacques
Jacques Barathon [MS]
"Gilles LAURENT [MVP]" wrote in message news:
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent.
Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et avoir déjà reçu cette même réponse de ta part... Ah là là, je vieillis...
Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a PyWin32 de récupérer les instances ouvertes via le CLSID. Utiliserait-il une API qui interroge une autre table? Si quelqu'un sait, ça m'intéresse.
Une solution de contournement consiste à parcourir la collection Windows de l'objet Shell.Application. La function VBScript ci-dessous retourne la première instance Internet Explorer en cours d'exécution.
Oui, c'est la technique que j'ai indiquée dans mon autre réponse, en proposant bien évidemment la version PowerShell... :-)
Jacques
"Gilles LAURENT [MVP]" <glsft@free.fr> wrote in message
news:6B13B18F-1811-4D05-97C2-7CB480B2ACA7@microsoft.com...
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution
dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject
(VBScript) ou GetActiveObject (.Net) échouent.
Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et avoir
déjà reçu cette même réponse de ta part... Ah là là, je vieillis...
Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a
PyWin32 de récupérer les instances ouvertes via le CLSID. Utiliserait-il une
API qui interroge une autre table? Si quelqu'un sait, ça m'intéresse.
Une solution de contournement
consiste à parcourir la collection Windows de l'objet Shell.Application.
La
function VBScript ci-dessous retourne la première instance Internet
Explorer
en cours d'exécution.
Oui, c'est la technique que j'ai indiquée dans mon autre réponse, en
proposant bien évidemment la version PowerShell... :-)
Le server COM Internet Explorer n'enregistre pas ses instances d'exécution dans la ROT (Running Object Table). C'est pourquoi les méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent.
Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et avoir déjà reçu cette même réponse de ta part... Ah là là, je vieillis...
Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a PyWin32 de récupérer les instances ouvertes via le CLSID. Utiliserait-il une API qui interroge une autre table? Si quelqu'un sait, ça m'intéresse.
Une solution de contournement consiste à parcourir la collection Windows de l'objet Shell.Application. La function VBScript ci-dessous retourne la première instance Internet Explorer en cours d'exécution.
Oui, c'est la technique que j'ai indiquée dans mon autre réponse, en proposant bien évidemment la version PowerShell... :-)
Jacques
Méta-MCI \(MVP\)
Re !
Tu es sûr que la limitation est volontaire?
Une fois que l'on est "connecté" à un IE, j'ai eu plein de méthodes qui ne fonctionnent pas sous PS, alors que ça marche avec Jscript, Python, ou VBscript.
En cherchant pourquoi, je suis tombé, un jour, sur une page expliquant que c'était pour des raisons de sécurité (ce que je comprends, vu ce que j'arrive à faire avec). Malheureusement, je n'ai pas gardé le lien.
@+
Michel Claveau
Re !
Tu es sûr que la limitation est volontaire?
Une fois que l'on est "connecté" à un IE, j'ai eu plein de méthodes qui
ne fonctionnent pas sous PS, alors que ça marche avec Jscript, Python,
ou VBscript.
En cherchant pourquoi, je suis tombé, un jour, sur une page expliquant
que c'était pour des raisons de sécurité (ce que je comprends, vu ce que
j'arrive à faire avec). Malheureusement, je n'ai pas gardé le lien.
Une fois que l'on est "connecté" à un IE, j'ai eu plein de méthodes qui ne fonctionnent pas sous PS, alors que ça marche avec Jscript, Python, ou VBscript.
En cherchant pourquoi, je suis tombé, un jour, sur une page expliquant que c'était pour des raisons de sécurité (ce que je comprends, vu ce que j'arrive à faire avec). Malheureusement, je n'ai pas gardé le lien.
@+
Michel Claveau
Gilles LAURENT [MVP]
"Jacques Barathon [MS]" a écrit dans le message de news:uepuzX% | "Gilles LAURENT [MVP]" wrote in message | news: | || Le server COM Internet Explorer n'enregistre pas ses instances || d'exécution dans la ROT (Running Object Table). C'est pourquoi les || méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent. | | Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et | avoir déjà reçu cette même réponse de ta part... Ah là là, je | vieillis...
Hé hé :-) Comme tout le monde !
| Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a | PyWin32 de récupérer les instances ouvertes via le CLSID. | Utiliserait-il une API qui interroge une autre table? Si quelqu'un | sait, ça m'intéresse.
Le CLSID utilisé par Michel n'est autre que celui de l'objet ShellWindows : http://msdn2.microsoft.com/en-us/library/bb773974(VS.85).aspx
C'est en fait l'interface de l'objet COM (Shell.Application).Windows
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de
news:uepuzX%23mIHA.484@TK2MSFTNGP06.phx.gbl
| "Gilles LAURENT [MVP]" <glsft@free.fr> wrote in message
| news:6B13B18F-1811-4D05-97C2-7CB480B2ACA7@microsoft.com...
|
|| Le server COM Internet Explorer n'enregistre pas ses instances
|| d'exécution dans la ROT (Running Object Table). C'est pourquoi les
|| méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent.
|
| Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et
| avoir déjà reçu cette même réponse de ta part... Ah là là, je
| vieillis...
Hé hé :-) Comme tout le monde !
| Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a
| PyWin32 de récupérer les instances ouvertes via le CLSID.
| Utiliserait-il une API qui interroge une autre table? Si quelqu'un
| sait, ça m'intéresse.
Le CLSID utilisé par Michel n'est autre que celui de l'objet
ShellWindows :
http://msdn2.microsoft.com/en-us/library/bb773974(VS.85).aspx
C'est en fait l'interface de l'objet COM (Shell.Application).Windows
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"Jacques Barathon [MS]" a écrit dans le message de news:uepuzX% | "Gilles LAURENT [MVP]" wrote in message | news: | || Le server COM Internet Explorer n'enregistre pas ses instances || d'exécution dans la ROT (Running Object Table). C'est pourquoi les || méthodes GetObject (VBScript) ou GetActiveObject (.Net) échouent. | | Ah oui, c'est vrai. Je me rappelle avoir eu cette même discussion et | avoir déjà reçu cette même réponse de ta part... Ah là là, je | vieillis...
Hé hé :-) Comme tout le monde !
| Mais dans ce cas, je suis quand même intrigué par la possibilité qu'a | PyWin32 de récupérer les instances ouvertes via le CLSID. | Utiliserait-il une API qui interroge une autre table? Si quelqu'un | sait, ça m'intéresse.
Le CLSID utilisé par Michel n'est autre que celui de l'objet ShellWindows : http://msdn2.microsoft.com/en-us/library/bb773974(VS.85).aspx
C'est en fait l'interface de l'objet COM (Shell.Application).Windows
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonsoir !
Le CLSID utilisé par Michel n'est autre que celui de l'objet ShellWindows
C'est exact. Sous Windows, jusqu'à IE-6 compris, Internet-Explorer et l'explorateur, c'était le même objet. On pouvait d'ailleurs taper une URL dans la barre d'adresse de l'explorateur, et voir le site à la place des fichiers d'une directory. Ou saisir "C:" dans Internet-Explorer, et voir la liste des fichiers.
Depuis IE-7, les deux objets sont séparés, mais restent très liés. Par exemple, taper "C:" dans Internet-Explorer ouvre une nouvelle fenêtre dans l'explorateur. Idem avec une adresse FTP: (c'est l'explorateur qui s'occupe du FTP). Inversement, taper une URL dans l'explorateur ouvre une nouvelle fenêtre dans Internet-Explorer.
Mais, le CLSID unique a été maintenu. Mon script Python fournit donc, à la fois les instances d'Internet-Explorer et celles de l'explorateur.
Les développeurs ont dû s'arracher pas mal de cheveux, pour maintenir cette cohérence du CLSID, tout en séparant les deux éléments...
@-salutations
Michel Claveau
Bonsoir !
Le CLSID utilisé par Michel n'est autre que celui de l'objet
ShellWindows
C'est exact. Sous Windows, jusqu'à IE-6 compris, Internet-Explorer et
l'explorateur, c'était le même objet. On pouvait d'ailleurs taper une
URL dans la barre d'adresse de l'explorateur, et voir le site à la place
des fichiers d'une directory. Ou saisir "C:" dans Internet-Explorer, et
voir la liste des fichiers.
Depuis IE-7, les deux objets sont séparés, mais restent très liés. Par
exemple, taper "C:" dans Internet-Explorer ouvre une nouvelle fenêtre
dans l'explorateur. Idem avec une adresse FTP: (c'est l'explorateur
qui s'occupe du FTP). Inversement, taper une URL dans l'explorateur
ouvre une nouvelle fenêtre dans Internet-Explorer.
Mais, le CLSID unique a été maintenu. Mon script Python fournit donc, à
la fois les instances d'Internet-Explorer et celles de l'explorateur.
Les développeurs ont dû s'arracher pas mal de cheveux, pour maintenir
cette cohérence du CLSID, tout en séparant les deux éléments...
Le CLSID utilisé par Michel n'est autre que celui de l'objet ShellWindows
C'est exact. Sous Windows, jusqu'à IE-6 compris, Internet-Explorer et l'explorateur, c'était le même objet. On pouvait d'ailleurs taper une URL dans la barre d'adresse de l'explorateur, et voir le site à la place des fichiers d'une directory. Ou saisir "C:" dans Internet-Explorer, et voir la liste des fichiers.
Depuis IE-7, les deux objets sont séparés, mais restent très liés. Par exemple, taper "C:" dans Internet-Explorer ouvre une nouvelle fenêtre dans l'explorateur. Idem avec une adresse FTP: (c'est l'explorateur qui s'occupe du FTP). Inversement, taper une URL dans l'explorateur ouvre une nouvelle fenêtre dans Internet-Explorer.
Mais, le CLSID unique a été maintenu. Mon script Python fournit donc, à la fois les instances d'Internet-Explorer et celles de l'explorateur.
Les développeurs ont dû s'arracher pas mal de cheveux, pour maintenir cette cohérence du CLSID, tout en séparant les deux éléments...
@-salutations
Michel Claveau
Méta-MCI \(MVP\)
Re !
Tout ça (message précédent) m'a amené à réfléchir à la question (essentielle) : qu'est-ce qu'un programme ?
Et la réponse est tout, sauf simple.
Au départ, c'est un ensemble d'instructions. Que l'on peut enregistrer dans un fichier. Mais, cela peut être, aussi, plusieurs ensembles d'instructions, qui peuvent être enregistrés dans plusieurs fichiers.
De plus, qu'est-ce qu'une instruction ? C'est un ordre, envoyé à ... à un équipement (OS, ou matériel, par exemple), ou à un autre programme, ou à une autre couche de programmation. Par exemple, l'instruction VBscript wscript.echo va envoyer un ordre à wscript, qui est un autre programme, le moteur de script, composant additionnel (facultatif mais utile) de Windows.
Si on en revient au fil, on se rend compte de la difficulté à identifier un programme, tel que Internet-Explorer.
En effet, qu'est "Internet-Explorer" ? Certes, c'est le nom d'un programme. Mais, comment l'identifier ? Le premier réflexe est d'utiliser le processus qui permet de le lancer (iexplore.exe). Mais, il y en a d'autres ; par exemple mshta.exe. Et, rien n'empêche de le renommer (en réalité, c'est difficile).
Le cas mshta.exe est intéressant. Si on lance: %WINDIR%mshta.exe http://google.fr On va bien naviguer sur Google, de manière pleinement fonctionnelle. Et pourtant, pas de trace du processus iexplore.exe, dans le gestionnaire de taches. Il n'est d'ailleurs pas identifié par les scripts pistant shell.application. Or, nul doute que les composants d'Internet-Explorer, nécessaires à la navigation, sont bien en cours d'exécution ; y compris un interface actif.
Alors, Internet-Explorer ou non ? Cette question devrait titiller beaucoup d'administrateurs.
Mais, je n'ai pas la réponse, car, finalement, après ces réflexions, hé bien... je ne sais plus ce qu'est un programme ;-)
@-salutations -- Michel Claveau
Re !
Tout ça (message précédent) m'a amené à réfléchir à la question
(essentielle) : qu'est-ce qu'un programme ?
Et la réponse est tout, sauf simple.
Au départ, c'est un ensemble d'instructions. Que l'on peut enregistrer
dans un fichier. Mais, cela peut être, aussi, plusieurs ensembles
d'instructions, qui peuvent être enregistrés dans plusieurs fichiers.
De plus, qu'est-ce qu'une instruction ? C'est un ordre, envoyé à ... à
un équipement (OS, ou matériel, par exemple), ou à un autre programme,
ou à une autre couche de programmation. Par exemple, l'instruction
VBscript wscript.echo va envoyer un ordre à wscript, qui est un autre
programme, le moteur de script, composant additionnel (facultatif mais
utile) de Windows.
Si on en revient au fil, on se rend compte de la difficulté à identifier
un programme, tel que Internet-Explorer.
En effet, qu'est "Internet-Explorer" ? Certes, c'est le nom d'un
programme. Mais, comment l'identifier ? Le premier réflexe est
d'utiliser le processus qui permet de le lancer (iexplore.exe). Mais, il
y en a d'autres ; par exemple mshta.exe. Et, rien n'empêche de le
renommer (en réalité, c'est difficile).
Le cas mshta.exe est intéressant. Si on lance: %WINDIR%mshta.exe
http://google.fr
On va bien naviguer sur Google, de manière pleinement fonctionnelle. Et
pourtant, pas de trace du processus iexplore.exe, dans le gestionnaire
de taches. Il n'est d'ailleurs pas identifié par les scripts pistant
shell.application.
Or, nul doute que les composants d'Internet-Explorer, nécessaires à la
navigation, sont bien en cours d'exécution ; y compris un interface
actif.
Alors, Internet-Explorer ou non ? Cette question devrait titiller
beaucoup d'administrateurs.
Mais, je n'ai pas la réponse, car, finalement, après ces réflexions, hé
bien... je ne sais plus ce qu'est un programme ;-)
Tout ça (message précédent) m'a amené à réfléchir à la question (essentielle) : qu'est-ce qu'un programme ?
Et la réponse est tout, sauf simple.
Au départ, c'est un ensemble d'instructions. Que l'on peut enregistrer dans un fichier. Mais, cela peut être, aussi, plusieurs ensembles d'instructions, qui peuvent être enregistrés dans plusieurs fichiers.
De plus, qu'est-ce qu'une instruction ? C'est un ordre, envoyé à ... à un équipement (OS, ou matériel, par exemple), ou à un autre programme, ou à une autre couche de programmation. Par exemple, l'instruction VBscript wscript.echo va envoyer un ordre à wscript, qui est un autre programme, le moteur de script, composant additionnel (facultatif mais utile) de Windows.
Si on en revient au fil, on se rend compte de la difficulté à identifier un programme, tel que Internet-Explorer.
En effet, qu'est "Internet-Explorer" ? Certes, c'est le nom d'un programme. Mais, comment l'identifier ? Le premier réflexe est d'utiliser le processus qui permet de le lancer (iexplore.exe). Mais, il y en a d'autres ; par exemple mshta.exe. Et, rien n'empêche de le renommer (en réalité, c'est difficile).
Le cas mshta.exe est intéressant. Si on lance: %WINDIR%mshta.exe http://google.fr On va bien naviguer sur Google, de manière pleinement fonctionnelle. Et pourtant, pas de trace du processus iexplore.exe, dans le gestionnaire de taches. Il n'est d'ailleurs pas identifié par les scripts pistant shell.application. Or, nul doute que les composants d'Internet-Explorer, nécessaires à la navigation, sont bien en cours d'exécution ; y compris un interface actif.
Alors, Internet-Explorer ou non ? Cette question devrait titiller beaucoup d'administrateurs.
Mais, je n'ai pas la réponse, car, finalement, après ces réflexions, hé bien... je ne sais plus ce qu'est un programme ;-)
En farfouillant un peu, je n'arrivais pas à bricoler Shell.Application depuis JScript. Après m'être arraché quelques cheveux, je suis tombé sur cette page : http://msdn2.microsoft.com/en-us/library/bb773972(VS.85).aspx
Où il est clairement marqué, dans _NewEnum Method , en fin du 1er paragraphe "example", ceci : "...This method cannot be used with Microsoft JScript."
Dur ! Dur !
Pourquoi cet ostracisme envers JScript ? Vais-je être obligé de me mettre au VBS ?
Très dur ! Très dur !
Sinon, connaissez-vous beaucoup de choses interdites à JScript, et autorisées à VBScript ? Ou, mieux, une doc ou un lien recensant ces problèmes ?
@-salutations -- Michel Claveau
Salut !
En farfouillant un peu, je n'arrivais pas à bricoler Shell.Application
depuis JScript.
Après m'être arraché quelques cheveux, je suis tombé sur cette page :
http://msdn2.microsoft.com/en-us/library/bb773972(VS.85).aspx
Où il est clairement marqué, dans _NewEnum Method , en fin du 1er
paragraphe "example", ceci :
"...This method cannot be used with Microsoft JScript."
Dur ! Dur !
Pourquoi cet ostracisme envers JScript ? Vais-je être obligé de me
mettre au VBS ?
Très dur ! Très dur !
Sinon, connaissez-vous beaucoup de choses interdites à JScript, et
autorisées à VBScript ?
Ou, mieux, une doc ou un lien recensant ces problèmes ?
En farfouillant un peu, je n'arrivais pas à bricoler Shell.Application depuis JScript. Après m'être arraché quelques cheveux, je suis tombé sur cette page : http://msdn2.microsoft.com/en-us/library/bb773972(VS.85).aspx
Où il est clairement marqué, dans _NewEnum Method , en fin du 1er paragraphe "example", ceci : "...This method cannot be used with Microsoft JScript."
Dur ! Dur !
Pourquoi cet ostracisme envers JScript ? Vais-je être obligé de me mettre au VBS ?
Très dur ! Très dur !
Sinon, connaissez-vous beaucoup de choses interdites à JScript, et autorisées à VBScript ? Ou, mieux, une doc ou un lien recensant ces problèmes ?
@-salutations -- Michel Claveau
MCI \(ex do ré Mi chel la si do\) [MVP]
Re !
à cause des parenthèses, il faut copier le lien, et le coller dans la barre d'adresse de IE, sinon, il ne trouve pas...
@+
MCI
Re !
à cause des parenthèses, il faut copier le lien, et le coller dans la
barre d'adresse de IE, sinon, il ne trouve pas...
