Petites observations...
Pour bien séparer le traitement:
Petites observations...
Pour bien séparer le traitement:
Petites observations...
Pour bien séparer le traitement:
"LE TROLL" <le wrote in message
news:Petites observations...
Hello,Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:
Petites observations...
Hello,
Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:Petites observations...
Hello,Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
OUI... chef !!!
Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
Mes respects chef, cordialement :o)
| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ;
OUI... chef !!!
Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
Mes respects chef, cordialement :o)
| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
OUI... chef !!!
Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
Mes respects chef, cordialement :o)
| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:Petites observations...
Hello,Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:
Petites observations...
Hello,
Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:Petites observations...
Hello,Pour bien séparer le traitement:
<snip>
Petites observations ...
C'est TRES bien de vouloir "séparer" les traitements,
et je te félicite de vouloir t'en préoccuper !
Cependant, encore faudait-il présenter à notre ami wess3310
la Bonne(tm) façon de faire :-)
Le faire avec une variable globale n'est PAS la bonne façon...
La bonne façon est la suivante:
Function IdentifierRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
Dim ret As Boolean
' ...
ret = SupprimerRep(rep, errCode)
If Not ret Then
' traitement eventuel de errCode
IdentifierRep = False
Else
' tout est ok
' suite du traitement
End If
End Function
Function SupprimerRep(ByVal rep As String, _
ByRef errCode As Long) As Boolean
On Error GoTo SupprimerRep_ERR
' faire le traitement
SupprimerRep = True
SupprimerRep_END:
Exit Function
SupprimerRep_ERR:
SupprimerRep = False
errCode = Err.Number
Resume SupprimerRep_END
End Function
Les avantages à pratiquer comme cela sont les suivants:
- Chaque fonction est indépendante des autres
- On peut réutiliser ces fonctions n'importe ou
- One ne créé pas un couplage artificiel et inutile avec
une variable globale
- Le code est limpide à lire
- Les intentions du programmeur sont clairement indiquées,
à tel point que ce code se passe de commentaires.
- etc.
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"LE TROLL" <le wrote in message
news:eLm%OUI... chef !!!
Ah, ça j'aime bien :-) Héhé ...Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par
erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
C'est tout à fait exact. L'idée est bien de propager sans
effets de bord. Ce que les fonctions et le mécanisme de
passage par référence (qui existent en Basic depuis le milieu
des années 80) permettent de réaliser de façon propre et
naturelle.
Note qu'on peut (et qu'on doit) généraliser:
le mieux est toujours de créer autant de procédures et
fonctions que nécessaire, pas seulement si elles risquent
de générer des erreurs, mais dès qu'une fraction de code peut
être réutilisable ou qu'il représente une unité sémantique
consistante.Mes respects chef, cordialement :o)
Mes respects également :-)
Bien cordialement,| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ;
"LE TROLL" <le troll@enfer.fr> wrote in message
news:eLm%23hAQCJHA.1628@TK2MSFTNGP02.phx.gbl...
OUI... chef !!!
Ah, ça j'aime bien :-) Héhé ...
Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par
erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
C'est tout à fait exact. L'idée est bien de propager sans
effets de bord. Ce que les fonctions et le mécanisme de
passage par référence (qui existent en Basic depuis le milieu
des années 80) permettent de réaliser de façon propre et
naturelle.
Note qu'on peut (et qu'on doit) généraliser:
le mieux est toujours de créer autant de procédures et
fonctions que nécessaire, pas seulement si elles risquent
de générer des erreurs, mais dès qu'une fraction de code peut
être réutilisable ou qu'il représente une unité sémantique
consistante.
Mes respects chef, cordialement :o)
Mes respects également :-)
Bien cordialement,
| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
"LE TROLL" <le wrote in message
news:eLm%OUI... chef !!!
Ah, ça j'aime bien :-) Héhé ...Je voulais dire, en fait, comme tu l'as compris, que quand du code risque
de
générer plusieurs erreurs, le mieux est de faire une procédure par
erreur,
comme ça on ne risque pas de se planter en faisant une salade, l'erreur
restant dans sa procédure.
C'est tout à fait exact. L'idée est bien de propager sans
effets de bord. Ce que les fonctions et le mécanisme de
passage par référence (qui existent en Basic depuis le milieu
des années 80) permettent de réaliser de façon propre et
naturelle.
Note qu'on peut (et qu'on doit) généraliser:
le mieux est toujours de créer autant de procédures et
fonctions que nécessaire, pas seulement si elles risquent
de générer des erreurs, mais dès qu'une fraction de code peut
être réutilisable ou qu'il représente une unité sémantique
consistante.Mes respects chef, cordialement :o)
Mes respects également :-)
Bien cordialement,| --
| Jean-marc Noury (jean_marc_n2)
| Microsoft MVP - Visual Basic
| FAQ VB: http://faq.vb.free.fr/
| mailto: remove '_no_spam_' ;
Salut Jean Marc,
je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
Salut Jean Marc,
je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
Salut Jean Marc,
je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
"Driss HANIB" wrote in message
news:Salut Jean Marc,
Salut Driss,je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
En programmation, ça à le même sens que le sens général:
en gros, c'est quand une modification dans une partie de
code a un impact (non désiré ou imprévu) à un tout autre
endroit.
Exemple:
Je déclare un tableau global d'une taille de 1000 éléments.
Dim t(1000) as Long
Puis j'écris une fonction qui lit les éléments de mon tableau:
Private Sub Command1_Click()
Dim i As Long
For i = 1 To 1000
Debug.Print t(i)
Next i
End Sub
Pour une raison quelconque, je décide de me limiter
à 100 éléments.
Je change donc va déclaration:
Dim t(100) as Long
Mais du coup, mon code va planter car j'ai oublié de
mettre à jour ma variable de compteur.
=> C'est un effet de bord: j'ai fait une modif à un
endroit, ça plante ailleurs.
Dans un gros programme avec des milliers de fonctions,
on imagine bien que ma modification pourrait passer
innaperçu et ne provoquer une erreur que bien plus tard,
des semaines ou des mois plus tard si ma fonction est rarement
appelée.
Et ce jour la, c'est l'enfer pour trouver le bug car il peut
être très compliqué de reproduire la situation amenant à ce bug.
Si on programme proprement, on n'emploie jamais dans du code ce
qu'on appelle des "nombres magiques" (1000 dans mon exemple).
On emploi des constantes symboliques, on écrit par exemple ceci:
Const SIZE_ARRAY As Long = 1000
Dim t(SIZE_ARRAY) As Long
Private Sub Command1_Click()
Dim i As Long
For i = 1 To SIZE_ARRAY
Debug.Print t(i)
Next i
End Sub
Le jour ou je change la taille de mon tableau,
je modifie une seule fois la constante et le tour est joué.
Les causes les plus fréquentes d'effets de bord,
ce sont:
- L'emploi de variables globales.
- L'emploi de valeurs magiques
- La non détection ou propagation des conditions d'erreur
En effet, plus le code "partage" une variable (variable globale)
ou un "secret" (une valeur numérique textuelle), plus il y a
de chances qu'une modification de cette variable entraine
des répercussions plus loin ou que le changement à une place
ne soit pas répercuté aux autres, entrainant un crash applicatif.
Depuis les années 80 et l'apparition des langages modernes,
concomitante avec la publication de résultats d'études sur
la qualité du code produit en fonction des habitudes ou
paradigmes de programmation, on sait que l'emploi de variables
dont on limite strictmeent la portée à un effet considérable
sur l'amélioration de la qualité du code (ie: moins de fautes).
Cordialement,
"Driss HANIB" <dhanib@club-internet.fr> wrote in message
news:udavsESCJHA.2292@TK2MSFTNGP02.phx.gbl...
Salut Jean Marc,
Salut Driss,
je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
En programmation, ça à le même sens que le sens général:
en gros, c'est quand une modification dans une partie de
code a un impact (non désiré ou imprévu) à un tout autre
endroit.
Exemple:
Je déclare un tableau global d'une taille de 1000 éléments.
Dim t(1000) as Long
Puis j'écris une fonction qui lit les éléments de mon tableau:
Private Sub Command1_Click()
Dim i As Long
For i = 1 To 1000
Debug.Print t(i)
Next i
End Sub
Pour une raison quelconque, je décide de me limiter
à 100 éléments.
Je change donc va déclaration:
Dim t(100) as Long
Mais du coup, mon code va planter car j'ai oublié de
mettre à jour ma variable de compteur.
=> C'est un effet de bord: j'ai fait une modif à un
endroit, ça plante ailleurs.
Dans un gros programme avec des milliers de fonctions,
on imagine bien que ma modification pourrait passer
innaperçu et ne provoquer une erreur que bien plus tard,
des semaines ou des mois plus tard si ma fonction est rarement
appelée.
Et ce jour la, c'est l'enfer pour trouver le bug car il peut
être très compliqué de reproduire la situation amenant à ce bug.
Si on programme proprement, on n'emploie jamais dans du code ce
qu'on appelle des "nombres magiques" (1000 dans mon exemple).
On emploi des constantes symboliques, on écrit par exemple ceci:
Const SIZE_ARRAY As Long = 1000
Dim t(SIZE_ARRAY) As Long
Private Sub Command1_Click()
Dim i As Long
For i = 1 To SIZE_ARRAY
Debug.Print t(i)
Next i
End Sub
Le jour ou je change la taille de mon tableau,
je modifie une seule fois la constante et le tour est joué.
Les causes les plus fréquentes d'effets de bord,
ce sont:
- L'emploi de variables globales.
- L'emploi de valeurs magiques
- La non détection ou propagation des conditions d'erreur
En effet, plus le code "partage" une variable (variable globale)
ou un "secret" (une valeur numérique textuelle), plus il y a
de chances qu'une modification de cette variable entraine
des répercussions plus loin ou que le changement à une place
ne soit pas répercuté aux autres, entrainant un crash applicatif.
Depuis les années 80 et l'apparition des langages modernes,
concomitante avec la publication de résultats d'études sur
la qualité du code produit en fonction des habitudes ou
paradigmes de programmation, on sait que l'emploi de variables
dont on limite strictmeent la portée à un effet considérable
sur l'amélioration de la qualité du code (ie: moins de fautes).
Cordialement,
"Driss HANIB" wrote in message
news:Salut Jean Marc,
Salut Driss,je saute sur l'occasion que me donne ton mail pour te demander ce que tu
entends par "Effet de bord" ?
Je vois bien le principe, mais pas en programmation..
peux tu me donner un exemple ?
En programmation, ça à le même sens que le sens général:
en gros, c'est quand une modification dans une partie de
code a un impact (non désiré ou imprévu) à un tout autre
endroit.
Exemple:
Je déclare un tableau global d'une taille de 1000 éléments.
Dim t(1000) as Long
Puis j'écris une fonction qui lit les éléments de mon tableau:
Private Sub Command1_Click()
Dim i As Long
For i = 1 To 1000
Debug.Print t(i)
Next i
End Sub
Pour une raison quelconque, je décide de me limiter
à 100 éléments.
Je change donc va déclaration:
Dim t(100) as Long
Mais du coup, mon code va planter car j'ai oublié de
mettre à jour ma variable de compteur.
=> C'est un effet de bord: j'ai fait une modif à un
endroit, ça plante ailleurs.
Dans un gros programme avec des milliers de fonctions,
on imagine bien que ma modification pourrait passer
innaperçu et ne provoquer une erreur que bien plus tard,
des semaines ou des mois plus tard si ma fonction est rarement
appelée.
Et ce jour la, c'est l'enfer pour trouver le bug car il peut
être très compliqué de reproduire la situation amenant à ce bug.
Si on programme proprement, on n'emploie jamais dans du code ce
qu'on appelle des "nombres magiques" (1000 dans mon exemple).
On emploi des constantes symboliques, on écrit par exemple ceci:
Const SIZE_ARRAY As Long = 1000
Dim t(SIZE_ARRAY) As Long
Private Sub Command1_Click()
Dim i As Long
For i = 1 To SIZE_ARRAY
Debug.Print t(i)
Next i
End Sub
Le jour ou je change la taille de mon tableau,
je modifie une seule fois la constante et le tour est joué.
Les causes les plus fréquentes d'effets de bord,
ce sont:
- L'emploi de variables globales.
- L'emploi de valeurs magiques
- La non détection ou propagation des conditions d'erreur
En effet, plus le code "partage" une variable (variable globale)
ou un "secret" (une valeur numérique textuelle), plus il y a
de chances qu'une modification de cette variable entraine
des répercussions plus loin ou que le changement à une place
ne soit pas répercuté aux autres, entrainant un crash applicatif.
Depuis les années 80 et l'apparition des langages modernes,
concomitante avec la publication de résultats d'études sur
la qualité du code produit en fonction des habitudes ou
paradigmes de programmation, on sait que l'emploi de variables
dont on limite strictmeent la portée à un effet considérable
sur l'amélioration de la qualité du code (ie: moins de fautes).
Cordialement,
jean-marc a écrit le 28/08/2008 à 12h50 :"LE TROLL" <le wrote in message
news:
je vais t'expliquer mes besoins exactement
sous windows il ya des repertoires generalemenet cachés qui sont nommés :
$NtUninstallKB904942$
il ya d'autres repertoires qui ont a peut pret le meme nom sous ces repertoire
on a les hotfixes
mois je veux supprimer soit le contenue de ces repertoires
soit les repertoire et leur contenue
est-ce-qu'il existe un code qui permet cette operation
merci beaucoup beaucoup beaucoup
jean-marc a écrit le 28/08/2008 à 12h50 :
"LE TROLL" <le wrote in message
news:
je vais t'expliquer mes besoins exactement
sous windows il ya des repertoires generalemenet cachés qui sont nommés :
$NtUninstallKB904942$
il ya d'autres repertoires qui ont a peut pret le meme nom sous ces repertoire
on a les hotfixes
mois je veux supprimer soit le contenue de ces repertoires
soit les repertoire et leur contenue
est-ce-qu'il existe un code qui permet cette operation
merci beaucoup beaucoup beaucoup
jean-marc a écrit le 28/08/2008 à 12h50 :"LE TROLL" <le wrote in message
news:
je vais t'expliquer mes besoins exactement
sous windows il ya des repertoires generalemenet cachés qui sont nommés :
$NtUninstallKB904942$
il ya d'autres repertoires qui ont a peut pret le meme nom sous ces repertoire
on a les hotfixes
mois je veux supprimer soit le contenue de ces repertoires
soit les repertoire et leur contenue
est-ce-qu'il existe un code qui permet cette operation
merci beaucoup beaucoup beaucoup