supprimer repertoires

Petites observations...


''''' On Error Resume Next
ON ERROR GOTO ERREUR
CheminRep = DossierSpecial(36)
If Right(CheminRep, 1) <> "" Then CheminRep = CheminRep + ""
CheminRep = CheminRep + "*.*"
Kill CheminRep
''' List1.Refresh ''' POURQUOI rafraîchir 1 liste que tu mets à 0 ensuite
(clear) ???
list1.clear
error goto 0
EXIT SUB
ERREUR:
'....
----------------------

Pour bien séparer le traitement:

dim errFichier as long
sub identifieRep()
...
call supprimerRep
if errFichier <> 0 then ...
end sub
'''''''''''''''''''''''''''''''''''''''''''''''''''''

Sub supprimeRep()
on error goto erreur
...
exit sub
erreur:
errFichier = error
end sub



------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"wess3310" <wess3310@domain-xyz.in> a écrit dans le message de news:
tb-dne9Sl5IarSjV4p2dnAA@giganews.com...
| Bonjour,
|
| voila mon code
| '''''''
| On Error Resume Next
| CheminRep = DossierSpecial(36)
| If Right(CheminRep, 1) <> "" Then CheminRep = CheminRep + ""
| CheminRep = CheminRep + "*.*"
|
| Kill CheminRep
| List1.Refresh
| List1.Clear
| On Error GoTo 0
|
| '''''''''''''''''''''''''''''''''''
| il me permet de supprimer le contenue d'un repertoire mais seulement les
| fichiers *.*
| j'ai besoin de supprimer les sous repertoires aussi *
| merci beaucoup beaucoup beaucoup

"LE TROLL" <le troll@enfer.fr> wrote in message
news:OmX7ssOCJHA.5656@TK2MSFTNGP04.phx.gbl...

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_' ; _no_spam_jean_marc_n2@yahoo.fr

OUI... chef !!!

Moi j'aime pas les fonctions, elle rendent le code plus tortueux, et puis ce
n'est pas du Basic (procédure), mais en effet, on peut le faire ainsi en
"fonction"...

Sinon, ma variable globale, passait l'état de l'erreur de la procédure, elle
ne touchait pas à l'erreur, la laissant bien dans la procédure prévue
pour...

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)


--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"jean-marc" <jean_marc_n2@yahoo.fr.invalid> a écrit dans le message de news:
48b6830e$0$2855$ba620e4c@news.skynet.be...
|
| "LE TROLL" <le troll@enfer.fr> wrote in message
| news:OmX7ssOCJHA.5656@TK2MSFTNGP04.phx.gbl...
| > 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_' ; _no_spam_jean_marc_n2@yahoo.fr
|
|
|
|
|
|
|
|
|

jean-marc a écrit le 28/08/2008 à 12h50 :

"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_' ;

merci mon ami Jean-marc Noury
j'ai tappé le code
je suis un peut nul :D :D est-ce que tu peut m'expliquer plus ??
ou j'appelle ces fonction exactement pour que ca fonctionnent
merci mon ami

"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

jean-marc a écrit le 28/08/2008 à 12h50 :

"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_' ;

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

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 ?

merci d'avance

Driss


"jean-marc" <jean_marc_n2@yahoo.fr.invalid> a écrit dans le message de news:
48b6922b$0$2862$ba620e4c@news.skynet.be...

"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

"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,

--
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

jean-marc a écrit :

"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,

En LISP on utilise fréquemment l'effet de bord qui consiste dans ce cas
à utiliser le résultat d'une fonction alors qu'elle est appelée pour
réaliser autre chose :
ainsi l'affichage à l'écran est une procédure, et comme en LISP tout est
fonction et donc renvoie un résultat (c'est par extension que l'on
considère des fonctions qui renvoient Null comme résultat). Dans le cas
de Print la fonction renvoie l'évaluation de son argument. On parle
d'effet de bord car ce n'est pas ce qui est demandé principalement à la
fonction print. Ce n'est cependant pas une erreur.

l'expression suivante
(print (+ 2 (print (+ 2 (print 2))))
Affichera
2
4
6

Il est à remarquer que dans ces types de langages, il n'y a pas de
variables globales (plus exactement elles ne se programment pas
naturellement) et les variables locales sont essentiellement des
paramètres de fonction. On peut faire un programme relativement costaud
en LISP sans utiliser une seule variable et seulement des compositions
de fonction utilisant des paramètres (je l'ai fait pour un jeu de dames).

Bonjour,
wess3310 a écrit :

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

Pour ce cas particulier, il y a ceci, en vbscript, avec contrôle de
cohérence avec le registre, qu'il n'est pas superflu de prendre en
compte pour ces répertoires. Reste plus qu'à transcrire adapter en VB :

<http://www.bellamyjc.org/fr/vbsdownload.html#deluninstall>

un classique ;-)

PS : je ne fait que passer :-)

--

Cordialement,

Jacques.