Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Fermer par END

Fermer par END

4 réponses
Avatar
le_troll
Bonjour,

Il y a une petite polémique sur l'instruction "END", alors voici une
partie de ce que dit l'aide de Microsoft dans VB6:

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 desfeuilles et desmodules de classe 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 Open 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.

Donc, les fichiers sont fermés, la mémoire est vidée (occupation des
variables), les liens sont détruits, le code n'est plus exécuté évidmment,
alors, il reste quoi en mémoire, que je comprenne ???

Un exemple MicroSoft:
Sub Form_Load
Dim Password, Pword
PassWord = "Sésame"
Pword = InputBox("Tapez votre mot de passe")
If Pword <> PassWord Then
MsgBox "Mot de passe incorrect"
End
End If
End Sub

Microsft lui-même donne un exemple avec END, alors si c'était non
préconisé, ferait-il une chose pareille?

Je viens de tester, la mémoire se vide bien, le processus se ferme bien
avec END...

Merci pour les explication à partir de ce qui est écrit et sus-cité par
Microsoft :o)


--
Merci, @+, bye, Joe
troll75 AROBASE iFrance POINT com
------------------------------------------
Ce message est plein de virus "certifiés"
Le_Troll, éleveur de Trolls depuis César, qui disait:
Avec une hache, celui qui tient le manche a toujours raison !
------------------------------------------
Signaler un problème avec ce contenu

4 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
François Picalausa
Hello,

Un exemple MicroSoft:


Beaucoup d'exemple ont apparement été écrits par des gens inexpérimentés en
VB...
Regarde déjà cette ligne:
Dim Password, Pword


Du variant! Quelle horreur quand du string va beaucoup plus vite, prends
moins de place, ...

Le *seul* intéret de l'exemple est AMHA la comparaison de chaines:
If Pword <> PassWord Then



Sinon personnellement, plutôt que de quitter brutalement la form si le mot
de passe n'est pas correcte, je préfère aborder le problème dans l'autre
sens et ne charger la form que si le mot de passe est correct (dans un sub
main)...

Maintenant, spécialement pour toi, je vais écrire un bout de code utilisant
End:
Dans un contrôle utilisateur:
Option Explicit

Private Declare Function CreateRectRgn _
Lib "gdi32" _
( _
ByVal X1 As Long, _
ByVal Y1 As Long, _
ByVal X2 As Long, _
ByVal Y2 As Long _
) _
As Long
Private Declare Function DeleteObject _
Lib "gdi32" _
( _
ByVal hObject As Long _
) _
As Long

Private Regions(999) As Long
Private Loaded As Boolean

Private Sub UserControl_Initialize()
Loaded = False
End Sub

Private Sub UserControl_Show()
If Ambient.UserMode And Not Loaded Then
Loaded = True
Dim i As Long

For i = 0 To 999
Regions(i) = CreateRectRgn(0, 0, 200, 200)
Next i
End If
End Sub

Private Sub UserControl_Terminate()
If Loaded Then
Dim i As Long

For i = 0 To 999
DeleteObject Regions(i)
Next i
End If
End Sub


Dans un form avec un commandbutton, command1:
Option Explicit

Private Sub Command1_Click()
End
End Sub


Sous XP, Ctrl+Alt+Del, onglet processus
Menu affichage > sélectionner le colonnes > objets GDI
et regarder l'évolution des objets du GDI et en parallèle la mémoire
utilisée...
Ca monte, ça monte, ça monte... - oooups, je viens de planter VB...
véridique - démonstration réussie :-)
Ici les ressources sont probablement détruites par windows après l'arrète du
programme mais d'autres opérations allouant de la mémoire
pourrait être nettement plus consommatrices et ne pas être gentiment
désallouées par windows... et qui te dit ce qu'un objet com fait réellement?
Donc, End est réellement la dernière roue de secours à n'employer que si
false = true et jamais autrement... (quoi que ces conditions sont encore
trop larges à mon goût)... aucune polémique possible: end est mauvais dans
99,999% des cas (les 0,001% restant étant le cas où vb "pense" que
false=true... auquel cas il n'y a plus grand chose à faire mis à part
éteindre le processeur en feu ;-) )!

Et comme tu avais commencé sur l'aide concernant l'instruction end:
"The End statement provides a way to force your program to halt. For normal
termination of a Visual Basic program, you should unload all forms."
(L'instruction End offre un moyen pour *forcer* l'arrêt de votre programme.
Pour un arrêt *normal* d'un programme Visual Basic, vous devriez décharger
toutes les forms).

--
François Picalausa (MVP VB)
http://faq.vb.free.fr --- http://msdn.microsoft.com
http://apisvb.europe.webmatrixhosting.net

"le_troll" a écrit dans le message de
news:%
Avatar
le_troll
Bonjour,

Unload.form1 donc ???

--
Merci, @+, bye, Joe
troll75 AROBASE iFrance POINT com
------------------------------------------
Ce message est plein de virus "certifiés"
Le_Troll, éleveur de Trolls depuis César, qui disait:
Avec une hache, celui qui tient le manche a toujours raison !
------------------------------------------


"François Picalausa" a écrit dans le message de news:

Hello,

> Un exemple MicroSoft:
Beaucoup d'exemple ont apparement été écrits par des gens inexpérimentés


en
VB...
Regarde déjà cette ligne:
> Dim Password, Pword
Du variant! Quelle horreur quand du string va beaucoup plus vite, prends
moins de place, ...

Le *seul* intéret de l'exemple est AMHA la comparaison de chaines:
> If Pword <> PassWord Then

Sinon personnellement, plutôt que de quitter brutalement la form si le mot
de passe n'est pas correcte, je préfère aborder le problème dans l'autre
sens et ne charger la form que si le mot de passe est correct (dans un sub
main)...

Maintenant, spécialement pour toi, je vais écrire un bout de code


utilisant
End:
Dans un contrôle utilisateur:
Option Explicit

Private Declare Function CreateRectRgn _
Lib "gdi32" _
( _
ByVal X1 As Long, _
ByVal Y1 As Long, _
ByVal X2 As Long, _
ByVal Y2 As Long _
) _
As Long
Private Declare Function DeleteObject _
Lib "gdi32" _
( _
ByVal hObject As Long _
) _
As Long

Private Regions(999) As Long
Private Loaded As Boolean

Private Sub UserControl_Initialize()
Loaded = False
End Sub

Private Sub UserControl_Show()
If Ambient.UserMode And Not Loaded Then
Loaded = True
Dim i As Long

For i = 0 To 999
Regions(i) = CreateRectRgn(0, 0, 200, 200)
Next i
End If
End Sub

Private Sub UserControl_Terminate()
If Loaded Then
Dim i As Long

For i = 0 To 999
DeleteObject Regions(i)
Next i
End If
End Sub


Dans un form avec un commandbutton, command1:
Option Explicit

Private Sub Command1_Click()
End
End Sub


Sous XP, Ctrl+Alt+Del, onglet processus
Menu affichage > sélectionner le colonnes > objets GDI
et regarder l'évolution des objets du GDI et en parallèle la mémoire
utilisée...
Ca monte, ça monte, ça monte... - oooups, je viens de planter VB...
véridique - démonstration réussie :-)
Ici les ressources sont probablement détruites par windows après l'arrète


du
programme mais d'autres opérations allouant de la mémoire
pourrait être nettement plus consommatrices et ne pas être gentiment
désallouées par windows... et qui te dit ce qu'un objet com fait


réellement?
Donc, End est réellement la dernière roue de secours à n'employer que si
false = true et jamais autrement... (quoi que ces conditions sont encore
trop larges à mon goût)... aucune polémique possible: end est mauvais dans
99,999% des cas (les 0,001% restant étant le cas où vb "pense" que
false=true... auquel cas il n'y a plus grand chose à faire mis à part
éteindre le processeur en feu ;-) )!

Et comme tu avais commencé sur l'aide concernant l'instruction end:
"The End statement provides a way to force your program to halt. For


normal
termination of a Visual Basic program, you should unload all forms."
(L'instruction End offre un moyen pour *forcer* l'arrêt de votre


programme.
Pour un arrêt *normal* d'un programme Visual Basic, vous devriez décharger
toutes les forms).

--
François Picalausa (MVP VB)
http://faq.vb.free.fr --- http://msdn.microsoft.com
http://apisvb.europe.webmatrixhosting.net

"le_troll" a écrit dans le message de
news:%




Avatar
François Picalausa
Hello,

Dans l'exemple, oui...

J'avais changé mon exemple pour placer le end dans le Form_Unload (avec le
même résultat). J'ai oublié de poster la modification... mais elle est
intéressante pour le Unload justement :-)
Mais dans ce cas d'un end dans un form unload (aka je gare ma voiture et
ensuite j'arrache le moteur), simplement enlever le End ne suffit pas
toujours. Exemple:
Private Sub Form_Load()
Form2.Show
End Sub
Private Sub Form_Unload(Cancel As Integer)
'Le End a été enlevé
End Sub

Dans ce cas ci, le programme ne se terminera pas de lui même.
On peut soit décharger toutes les forms:
Private Sub Form_Unload(Cancel As Integer)
Unload Form2
End Sub

Dont l'écriture plus systématique est
Private Sub Form_Unload(Cancel As Integer)
Dim frm As Form

For Each frm In Forms
If Not frm Is Me Then
Unload frm
End If
Next frm
End Sub

Mais plus simplement, si la form2 doit se décharger quand la form1 est
déchargée, on peut supposer que la form2 dépend de la form1 et en changer
son chargement:
Private Sub Form_Load()
Form2.Show , Me
End Sub

Les timers sont bien entendu à désactiver pour éviter que tout du code ne
"relance" le programme pendant la désactivation.... et pour le reste, cfr la
faq ;-)

--
François Picalausa (MVP VB)
http://faq.vb.free.fr --- http://msdn.microsoft.com
http://apisvb.europe.webmatrixhosting.net

"le_troll" a écrit dans le message de
news:
Bonjour,

Unload.form1 donc ???


Avatar
ng
Salut,

Sub Form_Load
Dim Password, Pword
PassWord = "Sésame"
Pword = InputBox("Tapez votre mot de passe")
If Pword <> PassWord Then
MsgBox "Mot de passe incorrect"
End
End If
End Sub



Cet exemple est une horreur, les variables ne sont mêmes pas typées et en
cas d'erreur ca terminé par un End !
End quitte bien sur corretement le processus (c'est un TerminateProcess())
mais ne libère absolument pas correctement les ressources. Il faut les
décharger manuellement proprement (forms, controles dynamiques (groupes...),
tableaux, grosses chaines...) et l'application quittera correctement.

--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/



le_troll a écrit :

Bonjour,

Il y a une petite polémique sur l'instruction "END", alors voici
une partie de ce que dit l'aide de Microsoft dans VB6:

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 desfeuilles et desmodules de classe
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 Open 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.

Donc, les fichiers sont fermés, la mémoire est vidée (occupation des
variables), les liens sont détruits, le code n'est plus exécuté
évidmment, alors, il reste quoi en mémoire, que je comprenne ???

Un exemple MicroSoft:
Sub Form_Load
Dim Password, Pword
PassWord = "Sésame"
Pword = InputBox("Tapez votre mot de passe")
If Pword <> PassWord Then
MsgBox "Mot de passe incorrect"
End
End If
End Sub

Microsft lui-même donne un exemple avec END, alors si c'était non
préconisé, ferait-il une chose pareille?

Je viens de tester, la mémoire se vide bien, le processus se
ferme bien avec END...

Merci pour les explication à partir de ce qui est écrit et
sus-cité par Microsoft :o)