End
Résolu
cs_JeffC1977
Messages postés
928
Date d'inscription
vendredi 10 novembre 2000
Statut
Membre
Dernière intervention
23 septembre 2023
-
4 juil. 2005 à 17:26
ScSami Messages postés 1488 Date d'inscription mercredi 5 février 2003 Statut Membre Dernière intervention 3 décembre 2007 - 6 juil. 2005 à 03:06
ScSami Messages postés 1488 Date d'inscription mercredi 5 février 2003 Statut Membre Dernière intervention 3 décembre 2007 - 6 juil. 2005 à 03:06
A voir également:
- Visual basic end
- Visual basic 2005 - Conseils pratiques -Visual Basic / VB.NET
- If visual basic - Conseils pratiques -Visual Basic / VB.NET
- Visual basic commentaire ✓ - Forum VB.NET
- Unexpected end of file from server - Forum Java
- Passer en commentaire plusieurs lignes de code VBA rapidement ✓ - Forum Visual Basic
9 réponses
Gobillot
Messages postés
3140
Date d'inscription
vendredi 14 mai 2004
Statut
Membre
Dernière intervention
11 mars 2019
34
4 juil. 2005 à 18:02
4 juil. 2005 à 18:02
oups !
ignore la fin du message précédent.
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
Dim F As Form
For Each F In Forms
Unload F
Next
End Sub
Daniel
ignore la fin du message précédent.
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
Dim F As Form
For Each F In Forms
Unload F
Next
End Sub
Daniel
Gobillot
Messages postés
3140
Date d'inscription
vendredi 14 mai 2004
Statut
Membre
Dernière intervention
11 mars 2019
34
4 juil. 2005 à 18:00
4 juil. 2005 à 18:00
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
Dim F As Form
For Each F In Forms
Unload F
Next
End Sub
Dim x As Integer
Label10 = "Query"
If UnloadMode 0 Then Cancel True
' Winsock.Close
' DoEvents
' Winsock.LocalPort = 0
' If Winsock.State > 0 Then MsgBox "Erreur Unload"
For x = 1 To 20: DoEvents: Next
Daniel
Dim F As Form
For Each F In Forms
Unload F
Next
End Sub
Dim x As Integer
Label10 = "Query"
If UnloadMode 0 Then Cancel True
' Winsock.Close
' DoEvents
' Winsock.LocalPort = 0
' If Winsock.State > 0 Then MsgBox "Erreur Unload"
For x = 1 To 20: DoEvents: Next
Daniel
cs_azerty25
Messages postés
1114
Date d'inscription
jeudi 19 décembre 2002
Statut
Membre
Dernière intervention
6 mai 2007
4 juil. 2005 à 21:10
4 juil. 2005 à 21:10
Ou bien tu met simplement end dans QueryUnload d'une form
@Z3RtY25 ==
@Z3RtY25 ==
Gobillot
Messages postés
3140
Date d'inscription
vendredi 14 mai 2004
Statut
Membre
Dernière intervention
11 mars 2019
34
4 juil. 2005 à 21:35
4 juil. 2005 à 21:35
End c'est la méthode barbare
surtout à éviter
Daniel
surtout à éviter
Daniel
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
24
5 juil. 2005 à 02:22
5 juil. 2005 à 02:22
Moi je suis pas d'accord!!! Ca c'est encore un truc de maniaque qui ne supporte pas de voir un seul GoTo dans le code!!!
End fait parfaitement l'affaire puisque Windows, quoi qu'on en dise,
remet tout en ordre derrière!!! Alors qu'on sorte par la porte de
devant, par la porte de derrière, par la fenêtre ou alors par la porte
de devant en fermant à celf, Dieu Windows, dans son infinie mansuétude,
fera de toutes façons brûler la maison!!! Alors qu'on arrête avec ça!!!
Non tu n'as ni besoin de Unload, ni besoin de _QueryUnload ni besoin de
End car si c'est ta seule fenêtre ou, tout du moins que toutes les
autres ont été unloadés, le programme se terminera sans broncher!
_QueryUnload est là juste pour permettre au programmeur d'intercepter,
justement, le clique sur cette croix (qui donc, appartient d'emblé aux
fenêtre [si, bien entendu, le programmeur ne l'a pas enlevée ce qui est
aussi possible !!!]). Par exemple, si tu mets un "Cancel = True" ça
annulera le clique de l'utilisateur et ta fenêtre ne pourra pas être
fermée... Enfin, je te laisse te reporter à l'aide du VB (la MSDN) pour
toutes les infos sur ce sujet...
Bon, ceci dit, Gobillot a quand même, quelque part, un peu raison même
si personnellement je te conseillerait de n'utiliser qu'un simple "End"
bien largement suffisant!!! Moi je suis partisant de ceci : Du moment
que ça fonctionne (correctement... sur du long terme donc), c'est le
principale... tout le reste n'est que choinoiserie inutiles (pardon
pour nos amis et futurs patrons les chinois mais c'est l'expression consacrée, que voulez-vous!!!)
Mais Gobillot pourrait peut-être, en quelques mots nous expliquer le
pouquoi il considère le "End" comme étant "barbare" et "à surtout
éviter" ???
Enjoy
<hr size="2" width="100%">
(Si une réponse vous convient, cliquez sur le bouton "Réponse accéptée"...)
End fait parfaitement l'affaire puisque Windows, quoi qu'on en dise,
remet tout en ordre derrière!!! Alors qu'on sorte par la porte de
devant, par la porte de derrière, par la fenêtre ou alors par la porte
de devant en fermant à celf, Dieu Windows, dans son infinie mansuétude,
fera de toutes façons brûler la maison!!! Alors qu'on arrête avec ça!!!
Non tu n'as ni besoin de Unload, ni besoin de _QueryUnload ni besoin de
End car si c'est ta seule fenêtre ou, tout du moins que toutes les
autres ont été unloadés, le programme se terminera sans broncher!
_QueryUnload est là juste pour permettre au programmeur d'intercepter,
justement, le clique sur cette croix (qui donc, appartient d'emblé aux
fenêtre [si, bien entendu, le programmeur ne l'a pas enlevée ce qui est
aussi possible !!!]). Par exemple, si tu mets un "Cancel = True" ça
annulera le clique de l'utilisateur et ta fenêtre ne pourra pas être
fermée... Enfin, je te laisse te reporter à l'aide du VB (la MSDN) pour
toutes les infos sur ce sujet...
Bon, ceci dit, Gobillot a quand même, quelque part, un peu raison même
si personnellement je te conseillerait de n'utiliser qu'un simple "End"
bien largement suffisant!!! Moi je suis partisant de ceci : Du moment
que ça fonctionne (correctement... sur du long terme donc), c'est le
principale... tout le reste n'est que choinoiserie inutiles (pardon
pour nos amis et futurs patrons les chinois mais c'est l'expression consacrée, que voulez-vous!!!)
Mais Gobillot pourrait peut-être, en quelques mots nous expliquer le
pouquoi il considère le "End" comme étant "barbare" et "à surtout
éviter" ???
Enjoy
<hr size="2" width="100%">
(Si une réponse vous convient, cliquez sur le bouton "Réponse accéptée"...)
Gobillot
Messages postés
3140
Date d'inscription
vendredi 14 mai 2004
Statut
Membre
Dernière intervention
11 mars 2019
34
5 juil. 2005 à 03:25
5 juil. 2005 à 03:25
Un programme Visual Basic se termine normalement lorsque tous les objets sont
déchargés et qu'il n'y a plus de code à exécuter. Pour terminer correctement
un programme il faut :
<li>Détruire tous les objets créés en écrivant Set MonObjet Nothing,</li><li>Décharger tous les formulaires à l'aide de l'instruction Unload,</li><li>Désactiver tous les timers actifs en écrivant Timer.Enabled False,
ceci afin d'éviter qu'ils n'enclenchent encore un évènement après la
fermeture du formulaire conteneur.</li>
Et pour être sûr de décharger totalement la mémoire, les paranos peuvent
aussi :
<li>Vider les variables "String" en écrivant varString "",</li><li>Vider les variables "Variant" en écrivant varVariant vbEmpty,</li><li>Détruire les tableaux en écrivant Erase Tableau ou Redim Tableau(0),</li>
Les variables numériques n'ont pas besoin d'être déchargées.
Il ne faut en aucun cas utiliser l'instruction "End" car elle force
l'arrêt du programme sans passer par les événements "Unload",
"Query_Unload" et "Terminate" des feuilles et des modules de
classe. De plus, elle ne détruit pas toujours les objets. Cette instruction
peut être à la limite employée dans une routine de gestion d'erreurs lors
d'erreurs graves.
Daniel
déchargés et qu'il n'y a plus de code à exécuter. Pour terminer correctement
un programme il faut :
<li>Détruire tous les objets créés en écrivant Set MonObjet Nothing,</li><li>Décharger tous les formulaires à l'aide de l'instruction Unload,</li><li>Désactiver tous les timers actifs en écrivant Timer.Enabled False,
ceci afin d'éviter qu'ils n'enclenchent encore un évènement après la
fermeture du formulaire conteneur.</li>
Et pour être sûr de décharger totalement la mémoire, les paranos peuvent
aussi :
<li>Vider les variables "String" en écrivant varString "",</li><li>Vider les variables "Variant" en écrivant varVariant vbEmpty,</li><li>Détruire les tableaux en écrivant Erase Tableau ou Redim Tableau(0),</li>
Les variables numériques n'ont pas besoin d'être déchargées.
Il ne faut en aucun cas utiliser l'instruction "End" car elle force
l'arrêt du programme sans passer par les événements "Unload",
"Query_Unload" et "Terminate" des feuilles et des modules de
classe. De plus, elle ne détruit pas toujours les objets. Cette instruction
peut être à la limite employée dans une routine de gestion d'erreurs lors
d'erreurs graves.
Daniel
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
24
5 juil. 2005 à 04:29
5 juil. 2005 à 04:29
Bon, que "End" mette directement fin au programme sans
demander l'avis de l'utilisateur moi je veux bien, mais dire qu'il ne
détruit pas toujours les objets, alors là, je ne suis plus d'accord!!!
Tout comme d'ailleurs ce qui concerne les Timers!!! Une fois que la
feuille est déchargé, y'a aucune chance pour qu'un quelconque ancien
Timer étant dessus déclanche une quelconque ancienne ligne de code puis
qu'il n'y a plus rien en mémoire !!!
Non, le fait est que ce qui dérange vraiment c'est que End met fin au
programme de manière un peu trop "brutale" pour certain et sans passer
par toutes ces maniaqueries de "parfait programmeur". Autrement dit, ce
qu'on lui reproche est plus de ne pas suivre la procédure
réglementaire! Procédure réglementaire prévue pour éviter aux codeurs
irresponçables d'oublier de demander l'avis de leurs utilisateurs pour
arrêter le programme.
Mais nous ne sommes pas non plus tous irresponçables lorsqu'on l'emploi!!!
Bref, personnellement je ne crois pas en l'argument technique ni même
en celui structurel ! Je crois juste qu'il est, un peu comme GoTo, un
peu trop efficace pour certain et qu'a ce titre il fait peur!!!
D'ailleurs, j'en veux pour preuve ce que dit la MSDN et qu'il faut savoir interprêter :
"Note L'instruction End met immédiatement
fin à l'exécution du code, sans appeler d'événement Unload, QueryUnload, ou
Terminate, ou tout autre code Visual Basic. Le code que vous avez écrit dans les
événements Unload, QueryUnload, et Terminate des
<object id= "alink_9" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"></object>feuilles et des
<object id="alink_10" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"></object> n'est pas exécuté. Les
objets créés depuis les modules de classe sont détruits, les fichiers ouverts au
moyen de l'instruction modules de classeOpen sont fermés et la mémoire occupée par le
programme est vidée
. Les références d'objet appartenant à d'autres programmes ne
sont plus valides."
Ca, au moins, c'est clair et factuel ! En revanche, ce qui suit l'est
nettement moins!!! C'est un avis déstiné à orienter notre
programmation... Autrement dit, c'est une suggestion de la philosophie
à adopter qui est... a prendre ou à laisser! Alors moi je vous accorde
que la MSDN est LA bible incontesté pour le VB mais en est-elle pour
autant Incontestable... telle est la question ! Je vous laisse méditer
ce point mais personnellement, me restant encore quelques cellules
critiques, je compte bien les utiliser encore longtemps à des fins
analytiques!
"L'instruction End permet de forcer l'arrêt du programme.
Pour qu'un programme Visual Basic se termine normalement, vous devez décharger
toutes les feuilles. Votre programme se termine lorsqu'il n'y a plus aucun
programme maintenant des références à des objets créés depuis vos modules de
classe publics et qu'aucun code n'est exécuté."
Alors, petite explication de texte : le mot "forcer" est loin d'être
techniquement vrai au vu du paragraphe précédent qui décrit à la
perfection l'utilité de cette instruction!!! Ensuite, il faut, bien
entendu, savoir relativier "vous devez décharger" !!! Bien sûr qu'on
peut le faire à la main, mais comme cette instruction le fait très bien
à notre place, pourquoi rajouter encore du code inutile !?!?!? C'est
pas très pragmatique comme approche vous trouvez pas ???
Bref, je ne cherche pas à convaincre mais à comprendre si je suis
vraiment complètement à coté de la plaque ou pas !?!?!?!?
Alors... aidez moi ou enfermez moi dans une boite (au moins, je serais plus chomeurs ;-), mais faites quelque chose
Enjoy
<hr size ="2" width="100%">
(Si une réponse vous convient, cliquez sur le bouton "Réponse accéptée"...)
demander l'avis de l'utilisateur moi je veux bien, mais dire qu'il ne
détruit pas toujours les objets, alors là, je ne suis plus d'accord!!!
Tout comme d'ailleurs ce qui concerne les Timers!!! Une fois que la
feuille est déchargé, y'a aucune chance pour qu'un quelconque ancien
Timer étant dessus déclanche une quelconque ancienne ligne de code puis
qu'il n'y a plus rien en mémoire !!!
Non, le fait est que ce qui dérange vraiment c'est que End met fin au
programme de manière un peu trop "brutale" pour certain et sans passer
par toutes ces maniaqueries de "parfait programmeur". Autrement dit, ce
qu'on lui reproche est plus de ne pas suivre la procédure
réglementaire! Procédure réglementaire prévue pour éviter aux codeurs
irresponçables d'oublier de demander l'avis de leurs utilisateurs pour
arrêter le programme.
Mais nous ne sommes pas non plus tous irresponçables lorsqu'on l'emploi!!!
Bref, personnellement je ne crois pas en l'argument technique ni même
en celui structurel ! Je crois juste qu'il est, un peu comme GoTo, un
peu trop efficace pour certain et qu'a ce titre il fait peur!!!
D'ailleurs, j'en veux pour preuve ce que dit la MSDN et qu'il faut savoir interprêter :
"Note L'instruction End met immédiatement
fin à l'exécution du code, sans appeler d'événement Unload, QueryUnload, ou
Terminate, ou tout autre code Visual Basic. Le code que vous avez écrit dans les
événements Unload, QueryUnload, et Terminate des
<object id= "alink_9" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"></object>feuilles et des
<object id="alink_10" type="application/x-oleobject" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"></object> n'est pas exécuté. Les
objets créés depuis les modules de classe sont détruits, les fichiers ouverts au
moyen de l'instruction modules de classeOpen sont fermés et la mémoire occupée par le
programme est vidée
. Les références d'objet appartenant à d'autres programmes ne
sont plus valides."
Ca, au moins, c'est clair et factuel ! En revanche, ce qui suit l'est
nettement moins!!! C'est un avis déstiné à orienter notre
programmation... Autrement dit, c'est une suggestion de la philosophie
à adopter qui est... a prendre ou à laisser! Alors moi je vous accorde
que la MSDN est LA bible incontesté pour le VB mais en est-elle pour
autant Incontestable... telle est la question ! Je vous laisse méditer
ce point mais personnellement, me restant encore quelques cellules
critiques, je compte bien les utiliser encore longtemps à des fins
analytiques!
"L'instruction End permet de forcer l'arrêt du programme.
Pour qu'un programme Visual Basic se termine normalement, vous devez décharger
toutes les feuilles. Votre programme se termine lorsqu'il n'y a plus aucun
programme maintenant des références à des objets créés depuis vos modules de
classe publics et qu'aucun code n'est exécuté."
Alors, petite explication de texte : le mot "forcer" est loin d'être
techniquement vrai au vu du paragraphe précédent qui décrit à la
perfection l'utilité de cette instruction!!! Ensuite, il faut, bien
entendu, savoir relativier "vous devez décharger" !!! Bien sûr qu'on
peut le faire à la main, mais comme cette instruction le fait très bien
à notre place, pourquoi rajouter encore du code inutile !?!?!? C'est
pas très pragmatique comme approche vous trouvez pas ???
Bref, je ne cherche pas à convaincre mais à comprendre si je suis
vraiment complètement à coté de la plaque ou pas !?!?!?!?
Alors... aidez moi ou enfermez moi dans une boite (au moins, je serais plus chomeurs ;-), mais faites quelque chose
Enjoy
<hr size ="2" width="100%">
(Si une réponse vous convient, cliquez sur le bouton "Réponse accéptée"...)
Gobillot
Messages postés
3140
Date d'inscription
vendredi 14 mai 2004
Statut
Membre
Dernière intervention
11 mars 2019
34
5 juil. 2005 à 12:55
5 juil. 2005 à 12:55
Il est vrai que chacun peut faire ce qu'il veut dans son petit coin,
quand j'ai commencé la programmation personne ne disait qu'il ne
fallait pas utiliser telle ou telle instruction, toute la mémoire était
à notre disposition et on emmerdait personne.
Depuis des nouvelles méthodes de programmation sont arrivées et sous
prétexte de non compréhension par certains, je dirais plutot par des
non informaticiens qui comprenant rien au jargon informatique voulait
quand même faire leur intéressant et imposer des règles qui ressemblent
plus à des exercices scolaires comme par exemple écrire un livre
complet sans utiliser la lettre "e" ou faire un programme complet sans
utiliser le "Go To",
ce qui est impossible en assembleur.
Il est vrai que le "Go To" casse le rythme mais parfois on ne peut pas
vraiment faire autrement, et personne ne ralera si après compilation du
programme il trove qu'il est bardé de "Go To" même si dans la source il
n'y en a aucun.
Je ne suis donc pas un parano des méthodes imposées par les hommes en
blanc, ceux qui sont dans leur tour d'ivoire et qui n'ont rien à faire
d'autre que d'imposer des règles idiotes qui n'ont rien à voir avec la
programmation.
L'important c'est d'être logique avec soi même et d'être en accord avec
le langage qu'on utilise. Maintenant on ne travaille plus dans son
petit coin, il faut prendre en compte que d'autres travaillent en même
temps que vous, ne pas tirer toutes les couvertures (mémoire) à soi,
c'est à dire libérer le tout lorsque l'on a fini et rendre à César ce
qu'on a emprunté.
Lorsque l'on adopte un langage, on adopte aussi sa philosophie, bien
sûr l'adapter à notre mouture, mais se mettre en accord avec la
majorité, laisser tomber les règles inutiles pour ne garder que celles
qui sont justes et logiques, ceci vient avec le temps et l'expérience.
Bref le mieux est d'éviter le "Go To" quand il est pas obligatoire, ne
serait ce que pour ne pas faire râler les inconditionnels et surtout
quitter proprement son programme afin de ne pas se faire passer pour un
gros porc, c'est à dire laisser traîner ses détritus sans avoir
nettoyer la place, ce n'est qu'une question de respect envers les
autres et envers soi même.
Daniel
quand j'ai commencé la programmation personne ne disait qu'il ne
fallait pas utiliser telle ou telle instruction, toute la mémoire était
à notre disposition et on emmerdait personne.
Depuis des nouvelles méthodes de programmation sont arrivées et sous
prétexte de non compréhension par certains, je dirais plutot par des
non informaticiens qui comprenant rien au jargon informatique voulait
quand même faire leur intéressant et imposer des règles qui ressemblent
plus à des exercices scolaires comme par exemple écrire un livre
complet sans utiliser la lettre "e" ou faire un programme complet sans
utiliser le "Go To",
ce qui est impossible en assembleur.
Il est vrai que le "Go To" casse le rythme mais parfois on ne peut pas
vraiment faire autrement, et personne ne ralera si après compilation du
programme il trove qu'il est bardé de "Go To" même si dans la source il
n'y en a aucun.
Je ne suis donc pas un parano des méthodes imposées par les hommes en
blanc, ceux qui sont dans leur tour d'ivoire et qui n'ont rien à faire
d'autre que d'imposer des règles idiotes qui n'ont rien à voir avec la
programmation.
L'important c'est d'être logique avec soi même et d'être en accord avec
le langage qu'on utilise. Maintenant on ne travaille plus dans son
petit coin, il faut prendre en compte que d'autres travaillent en même
temps que vous, ne pas tirer toutes les couvertures (mémoire) à soi,
c'est à dire libérer le tout lorsque l'on a fini et rendre à César ce
qu'on a emprunté.
Lorsque l'on adopte un langage, on adopte aussi sa philosophie, bien
sûr l'adapter à notre mouture, mais se mettre en accord avec la
majorité, laisser tomber les règles inutiles pour ne garder que celles
qui sont justes et logiques, ceci vient avec le temps et l'expérience.
Bref le mieux est d'éviter le "Go To" quand il est pas obligatoire, ne
serait ce que pour ne pas faire râler les inconditionnels et surtout
quitter proprement son programme afin de ne pas se faire passer pour un
gros porc, c'est à dire laisser traîner ses détritus sans avoir
nettoyer la place, ce n'est qu'une question de respect envers les
autres et envers soi même.
Daniel
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
24
6 juil. 2005 à 03:06
6 juil. 2005 à 03:06
Gobillot, je suis bien d'accord, mais tu ne réponds pas
à ma question!!! Est-ce que je suis dans le vrai lorsque je prends à la
lettre ce que dit la MSDN (à savoir : "
Les
objets créés depuis les modules de classe sont détruits, les fichiers
ouverts au moyen de l'instruction Open sont fermés et
la mémoire occupée par le programme est vidée
.") ou alors complètement à coté de la plaque ???
Autrement dit, ma question est simple :
- Si j'ai "raison", utiliser autre chose que "End" n'est pas pragmatique et donc à banier de nos habitudes
- Si j'ai "tort", j'aimerais savoir ce que, à ta connaissance, l'instruction "End" laisse en mémoire ???
Moi je suis bien d'accord qu'on n'est jamais seul ni à utiliser l'ordi du client (en tant que programme )
ni à coder un prog (en tant que membre d'une équipe). Mais lorsqu'une
habitude, une coutume (ou autre) est profondément infondée, inutile,
(...) ben faut l'abandonner non !?!?!?
Donc, moi je veux que tous les "pros" de VBF me dise qu'il faut
utiliser les Unload, mais j'aimerais savoir le pourquoi du comment car
il n'est pas dans mes habitudes d'autodidacte têtu
de suivre le troupeau de mouton sans savoir pourquoi!!! Enfin, tu me
comprends quoi, c'est pas "l'envie de faire chier" qui m'anime mais
plutôt l'envie de "comprendre" !!!
Donc, une bonne fois pour toute : QU'EST-CE QUE L'INSTRUCTION "END" LAISSE EN MÉMOIRE QUE "UNLOAD" NE LAISSE PAS ?????????????
Enjoy
à ma question!!! Est-ce que je suis dans le vrai lorsque je prends à la
lettre ce que dit la MSDN (à savoir : "
Les
objets créés depuis les modules de classe sont détruits, les fichiers
ouverts au moyen de l'instruction Open sont fermés et
la mémoire occupée par le programme est vidée
.") ou alors complètement à coté de la plaque ???
Autrement dit, ma question est simple :
- Si j'ai "raison", utiliser autre chose que "End" n'est pas pragmatique et donc à banier de nos habitudes
- Si j'ai "tort", j'aimerais savoir ce que, à ta connaissance, l'instruction "End" laisse en mémoire ???
Moi je suis bien d'accord qu'on n'est jamais seul ni à utiliser l'ordi du client (en tant que programme )
ni à coder un prog (en tant que membre d'une équipe). Mais lorsqu'une
habitude, une coutume (ou autre) est profondément infondée, inutile,
(...) ben faut l'abandonner non !?!?!?
Donc, moi je veux que tous les "pros" de VBF me dise qu'il faut
utiliser les Unload, mais j'aimerais savoir le pourquoi du comment car
il n'est pas dans mes habitudes d'autodidacte têtu
de suivre le troupeau de mouton sans savoir pourquoi!!! Enfin, tu me
comprends quoi, c'est pas "l'envie de faire chier" qui m'anime mais
plutôt l'envie de "comprendre" !!!
Donc, une bonne fois pour toute : QU'EST-CE QUE L'INSTRUCTION "END" LAISSE EN MÉMOIRE QUE "UNLOAD" NE LAISSE PAS ?????????????
Enjoy
