événement Quitter d'une application

> Form_UnLoad() (ou Terminate ou QueryUnload, quel est le mieux
finalement ?)

QueryUnload() est conçu est à cet effet. Il se déclenche lorsque le
formulaire reçoit une demande de fermeture (tu peux vérifier d'où ça
provient). Tu n'as qu'à mettre Cancel = 1 pour annuler la demande.

If test = true then
msgbox "Message à mettre", vbapplicationmodal etc...,"Titre

Cancel = 1

Else
Ben, ça veut dire que testúlse donc là : End (ça ça va)
End If

End Sub

--
Cordialement
Yanick Lefebvre - MVP pour Visual Basic
Le français se refait une beauté, parlons en :
http://www.orthographe-recommandee.info/

Salut,

Dans l'événement Unload, mets Cancel à True :

Cancel = True '//annule la fermeture

Ben, ça veut dire que testúlse donc là : End (ça ça va)

Jamais END !!!!!!!!!!!!!!!!!!!!

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



Christian <chris.brooze@skynet.be> a écrit :

Re-bonjour,

Décidément, j'en demande mais je préfère séparer les différents
sujet...

J'aimerais lorsque mon application se ferme (sur l'événement
Terminate ou Unload ou que sais-je), elle effectue un test et si le
test s'avère négatif (ou positif, pareil), l'application ne se ferme
finalement pas tant que l'utilisateur n'a pas terminé qqch.

Donc :

Public Sub Form_UnLoad() (ou Terminate ou QueryUnload, quel est le
mieux finalement ?)

If test = true then
msgbox "Message à mettre", vbapplicationmodal etc...,"Titre
ICI : j'aimerais que l'application ne se ferme pas encore
tant que test n'est pas = false
Else
Ben, ça veut dire que testúlse donc là : End (ça ça va)
End If

End Sub

C'est sur la ligne ICI que j'aimerais trouvé l'instruction.

Encore meeeerrciiiiiiiii !

Salut, moi on m'a dit jadis de le mettre à (-1) Cancel, je l'utilise ainsi,
je pensais qu'il y avait une raison, mis à te lire, ça marcherait tant que
<> 0, j'apprends quelque chose là :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 !
------------------------------------------


"Zoury" <yanick_lefebvre@hotmail.com> a écrit dans le message de news:
OX4fb2UgEHA.216@tk2msftngp13.phx.gbl...

> Form_UnLoad() (ou Terminate ou QueryUnload, quel est le mieux
> finalement ?)

QueryUnload() est conçu est à cet effet. Il se déclenche lorsque le
formulaire reçoit une demande de fermeture (tu peux vérifier d'où ça
provient). Tu n'as qu'à mettre Cancel = 1 pour annuler la demande.

> If test = true then
> msgbox "Message à mettre", vbapplicationmodal etc...,"Titre
Cancel = 1
> Else
> Ben, ça veut dire que testúlse donc là : End (ça ça va)
> End If
>
> End Sub


--
Cordialement
Yanick Lefebvre - MVP pour Visual Basic
Le français se refait une beauté, parlons en :
http://www.orthographe-recommandee.info/

Eh, jamais "END", VB dit que ça ferme un programme, moult bouquins aussi,
moi je ferme toujours par END et je n'ai jamais eu de problème depuis un
lustre, alors je veux bien que tu aies raison avec "Unload Me", mais
faudrait encore me démontrer que ça plante...

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


"ng" <ng@ngsoft-fr.com> a écrit dans le message de news:
uWXaT4UgEHA.3548@TK2MSFTNGP09.phx.gbl...

Salut,

Dans l'événement Unload, mets Cancel à True :

Cancel = True '//annule la fermeture

> Ben, ça veut dire que testúlse donc là : End (ça ça va)

Jamais END !!!!!!!!!!!!!!!!!!!!

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



Christian <chris.brooze@skynet.be> a écrit :

> Re-bonjour,
>
> Décidément, j'en demande mais je préfère séparer les différents
> sujet...
>
> J'aimerais lorsque mon application se ferme (sur l'événement
> Terminate ou Unload ou que sais-je), elle effectue un test et si le
> test s'avère négatif (ou positif, pareil), l'application ne se ferme
> finalement pas tant que l'utilisateur n'a pas terminé qqch.
>
> Donc :
>
> Public Sub Form_UnLoad() (ou Terminate ou QueryUnload, quel est le
> mieux finalement ?)
>
> If test = true then
> msgbox "Message à mettre", vbapplicationmodal etc...,"Titre
> ICI : j'aimerais que l'application ne se ferme pas encore
> tant que test n'est pas = false
> Else
> Ben, ça veut dire que testúlse donc là : End (ça ça va)
> End If
>
> End Sub
>
> C'est sur la ligne ICI que j'aimerais trouvé l'instruction.
>
> Encore meeeerrciiiiiiiii !

Salut,

En fait il faut fixer la valeur True (-1 (VARIANT_BOOL) ou tte autre valeur
différente de 0).


--
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 <le_trol@paris.fr> a écrit :

Salut, moi on m'a dit jadis de le mettre à (-1) Cancel, je l'utilise
ainsi, je pensais qu'il y avait une raison, mis à te lire, ça
marcherait tant que <> 0, j'apprends quelque chose là :o)


"Zoury" <yanick_lefebvre@hotmail.com> a écrit dans le message de news:
OX4fb2UgEHA.216@tk2msftngp13.phx.gbl...

Form_UnLoad() (ou Terminate ou QueryUnload, quel est le mieux
finalement ?)

QueryUnload() est conçu est à cet effet. Il se déclenche lorsque le
formulaire reçoit une demande de fermeture (tu peux vérifier d'où ça
provient). Tu n'as qu'à mettre Cancel = 1 pour annuler la demande.

If test = true then
msgbox "Message à mettre", vbapplicationmodal etc...,"Titre

Cancel = 1

Else
Ben, ça veut dire que testúlse donc là : End (ça ça va)
End If

End Sub

--
Cordialement
Yanick Lefebvre - MVP pour Visual Basic
Le français se refait une beauté, parlons en :
http://www.orthographe-recommandee.info/

Salut,

Non c'est une horreur de faire ca, c'est l'équivalent de fermer ton appli
via TerminateProcess(), ca ne libère pas les ressources mémoires c'est un
vrai désastre.

Et comme disait je sais plus qui "Fermer un programme VB avec End revient à
arreter une voiture en arrachant le moteur ou en l'envoyant dans un mur."
C'est assez parlant comme image je trouve, non ?

http://faq.vb.free.fr/index.php?question

--
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 <le_trol@paris.fr> a écrit :

Eh, jamais "END", VB dit que ça ferme un programme, moult bouquins
aussi, moi je ferme toujours par END et je n'ai jamais eu de problème
depuis un lustre, alors je veux bien que tu aies raison avec "Unload
Me", mais faudrait encore me démontrer que ça plante...


"ng" <ng@ngsoft-fr.com> a écrit dans le message de news:
uWXaT4UgEHA.3548@TK2MSFTNGP09.phx.gbl...

Salut,

Dans l'événement Unload, mets Cancel à True :

Cancel = True '//annule la fermeture

Ben, ça veut dire que testúlse donc là : End (ça ça va)

Jamais END !!!!!!!!!!!!!!!!!!!!

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



Christian <chris.brooze@skynet.be> a écrit :

Re-bonjour,

Décidément, j'en demande mais je préfère séparer les différents
sujet...

J'aimerais lorsque mon application se ferme (sur l'événement
Terminate ou Unload ou que sais-je), elle effectue un test et si le
test s'avère négatif (ou positif, pareil), l'application ne se ferme
finalement pas tant que l'utilisateur n'a pas terminé qqch.

Donc :

Public Sub Form_UnLoad() (ou Terminate ou QueryUnload, quel est le
mieux finalement ?)

If test = true then
msgbox "Message à mettre", vbapplicationmodal etc...,"Titre
ICI : j'aimerais que l'application ne se ferme pas encore
tant que test n'est pas = false
Else
Ben, ça veut dire que testúlse donc là : End (ça ça va)
End If

End Sub

C'est sur la ligne ICI que j'aimerais trouvé l'instruction.

Encore meeeerrciiiiiiiii !

Hello,

Je n'ai pas pu m'empécher de lire:

moi je ferme toujours par END et je n'ai jamais eu de problème

"Fermer un programme VB avec End revient à arreter en l'envoyant dans un

mur."

moi je crash toujours ma voiture dans un mur pour l'arrêter, et je n'ai
jamais eu de problèmes
:-)

Eh, jamais "END", VB dit que ça ferme un programme

le_troll, effectivement VB dit que End arrête un programme:

<quote
src=http://msdn.microsoft.com/library/en-us/vbenlr98/html/vastmEnd.asp -
traduction non officielle>
Note L'instruction End arrête l'exécution du code abruptement, sans
invoquer les événements Unload, QueryUnload, ou Terminate, ou tout autre
code. Le code que vous avez placé dans les événements Unload, QueryUnload,
et Terminate des forms et modules de classes class modules ne sera pas
exécuté. Les objets créés à partire des modules de classe sont détruits, les
fichiers ouverts en utilisant l'instruction Open sont fermés et la mémoire
utilisée par votre programme est libérée. Les références maintenutes par
d'autres programmes sont invalidées.
L'instruction End vous offre un moyen de forcer votre programme à s'arrêter.
Pour un arrêt normal d'un programme Visual Basic, vous devriez décharger
toutes les forms. Votre programme se fermera aussi tôt que plus aucun
programme ne maintiendra de références aux objets créés à partir de vos
modules de classe publique et que plus aucun code n'est exécuté.
<quote>

Bien entendu, pour éviter tout problème, tu peux décharger tous les objets
proprement et ensuite appeler end, ce qui donnerait:
moi j'arrache toujours le moteur de ma voiture après l'avoir garée pour
l'arrêter, et je n'ai jamais eu de problèmes

Sinon, End vient de basics plus anciens ou END indiquait effectivement la
fin du programme. Aujourd'hui, il faut décharger tes objets proprements...
la première fois, ça peut parraitre difficile, la deuxième, on a un peu pris
la main mais on jette un oeil à la faq pour être sûr et très vite ça devient
un automatisme ;-)

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

"ng" <ng@ngsoft-fr.com> a écrit dans le message de
news:%23W6Ow2VgEHA.644@tk2msftngp13.phx.gbl

Eh, jamais "END", VB dit que ça ferme un programme, moult bouquins
aussi, moi je ferme toujours par END et je n'ai jamais eu de problème
depuis un lustre, alors je veux bien que tu aies raison avec "Unload
Me", mais faudrait encore me démontrer que ça plante...

Pour ce qui concerne l'utilisation de la mémoire et du End. Je ne suis pas
certain, mais je crois qu'il faut expliciter la différence entre la pile et
le tas. Pour les variables de type de base, elles sont stockées je présume
dans l'espace propre au programme . Dans ce cas le End doit en effet libérer
la mémoire. Par contre pour toutes les autres, même si les manipulations
d'allocation mémoire sont transparentes pour le programmeur de VB
(contrairement au C), il y a réservation d'un espace mémoire dans le "tas"
et la variable ne contient en réalité que l'adresse. A charge au programmeur
de charger et décharger les variables (load et unload) ce qui permet
effectivement de libérer toute la mémoire utilisée et pas seulement les
quatre octets contenant l'adresse.
Enfin pour voir les dégâts que feraient se genre de chose il est impératif
d'avoir des variables utilisant beaucoup de mémoire car sinon avec les 256
MO disponibles (enfin un peu moins c'est vrai) il faut un paquet de
variables textes de 12 caractères pour en venir à bout.
J'ai eu ce problème avec des tableaux dynamiques de PointAPI (huit octets
chacun et plusieurs milliers de points), j'oubliais de remettre mes tableaux
à zéro et ma mémoire se vidait inexorablement, cependant la plupart du temps
j'avais assez de mémoire pour que cela ne se voit pas. Il m'a fallu créer
une boucle qui utilisait un millier de fois ma procédure pour arriver à
planter le système et comprendre où était le problème qui semblait à priori
aléatoire.

Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture et
d'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste bien
sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du nom,
mais dans la plupart des cas nous avons

property get Nom()
Nom=m_Nom
end property

property set Nom(string Nom)
m_nom=Nom
end property

J'en profite pour rappeler ce qui est mon cheval de bataille depuis vingt
ans que je programme, "if condition = true" est redondant, "if condition "
suffit, c'est plus logique et plus rapide. L'utilisation des booléens n'est
pas encore réellement entrer dans les moeurs. Pour la plupart des langages
d'ailleurs true est toute valeur non nulle et false c'est bien sûr 0.
Pourquoi recommande-t-on "true = -1" ? Parce que -1 c'est 255, soit 11111111
et que lorsque l'on utilise le not bit à bit not(-1) vaut 0, c'est à dire
not(true) vaut false. D'ailleurs en C++ il y a une opération pour le non
logique qui est ! et une pour le non arithmétique qui est ~, les résultats
sont différents.

"Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...
<snip>

J'en profite pour rappeler ce qui est mon cheval de bataille depuis vingt
ans que je programme, "if condition = true" est redondant, "if condition "
suffit, c'est plus logique et plus rapide.

Hello,

je paratge ce point de vue, avec cependant quelques commentaires:

Pour ce qui est de l'écriture ou non de "= TRUE" ,et bien en fait c'est plus
une question de contexte:

Si je teste a < b, il est évident que j'écris:
if a < b then
...
et pas
if (a < b) = TRUE then
...

Quand la condition est une fonction, 2 cas possibles:
- Soit ma fonction retourne un vrai booléen, et alors pas de soucis car mes
fonctions à valeur de retour booléennes d'appellent toujours is<qqchose>,
comme ça par exemple:

If isValidSwiftCharacter(c) Then
...
J'omets le =TRUE, car c'est évident et plus lisible

Mais si je suis obligé d'utiliser une fonction écrite par un autre, et que
cette fonction s'appelle "fctToto" alors 2 options:

OPTION 1
Je l'utilise telle quelle, je commente le fait que cette fonction est
stupide, surtout pour prévenir le programmeur suivant de faire gaffe, et
alors je fais apparaitre explicitement le = TRUE ou le úLSE

J'écrirais par exmple, en supposant que FctTOTO est FALSE quand tout est ok:

'
' Warning: usage of the dummy named function fctToto
' This function returns FALSE when all is ok and TRUE in other cases
'
If fctToto(a) = FALSE Then ' This stupid function returns FALSE if all is
ok
' ... blah blah, code for ok
Else
' fctToto = TRUE , means ERRROR
' ... code for error
Endif

OPTION 2
Je wrappe la stupide fonction dans une fonction à moi pour en faire une
Is<qqchose>.

Supposons que fctToto teste si un nombre est impair, en renvoyant FALSE si
le nombre est pair, TRUE si il est IMPAIR

alors je la wrappe comme ceci
'
' isOdd - Returns TRUE if n is an Odd (impair) number
' Returns FALSE if n is an Even (pair ) number
'
Function isOdd(Byref n as long) as Boolean
' use fctToto; this function returns TRUE if n is even
isOdd = fctToto(n)
End Function

et alors mon code applicatif redevient "normal" :

If isOdd(n) Then
...
Else
' n is even
' ...
Endif

Bien entendu, quelle que soit l'option choisie, la personne qui a appelé sa
fonction "fctToto" est retrouvé et (sévèrement) puni :-))

-
Jean-marc

"Patrice Henrio" <patrice.henrio.pasdepub@laposte.net> a écrit dans le
message de news:eED34v5hEHA.356@tk2msftngp13.phx.gbl...

Puisque nous en sommes aux questions théoriques, en voici une sur les
propriétés des objets ou classes.
Pourquoi faut-il les déclarer private et créer des procédures de lecture

et

d'écriture ?
En effet, à priori je sais ce que je programme et il me semble plus simple
décrire directement
objet.nom="Machin" ou if objet.condition then
sans que le programme fasse le détour par objet.setNom("Machin"), ou
objet.GetCondition.
Or dans les cours sur la POO (programmation orientée objet) on insiste

bien

sur le fait qu'il ne faut pas manipuler directement les propriétés. Je
repose ma question pourquoi ?
Je comprends si l'affectation doit faire plusieurs chose, par exemple en
plus de rentrer la propriété nom, renseigner la propriété longueur du nom,
mais dans la plupart des cas nous avons

property get Nom()
Nom=m_Nom
end property

property set Nom(string Nom)
m_nom=Nom
end property

Bonjour Patrice,

Lisant -a temps perdu- de vieux messages,
(et apprenant avec bcp d'interet les "SOLUTIONS POUR LA FONCTION PUBLIQUE"
precedents,
je vais rapidement te donner une "excellente" raison pratique
pour /en objet/ TOUJORUS passer par des Methodes, et non l'accès direct aux
données !

Tu sais que l'objectif /l'un des../ de l'objet, est de garantir independance
entre
code interne et externe de l'objet, en d'autres terme entre utilisation
et implementation (la façon dont c'est rtaité au niveau binaire ou...).

Passer par ces "méthodes" (le nom courant en technologie objet) libère le
programmeur utilisateur
de toute contrainte a ce niveau : un exemple => je viens de voir que
Currency disparait avec VB.NET
Comment vai-je choisir de le re-intercaler ?
dans certains cas, la precision Simple suffira, dans d'autre DOUBLE ou
meme Integer !
- quelque soir le choix du programmeur de la classe qui va refaire
l'implementation,
apr exemple en utilisant une classe de "COMPLEX" (idée farfelue en
l'occurrence),
avec en particulier une partie réelle partielle, ton programme utilisateur
ne sera pas concerné
du moment que tu respectes strictement l'interface de programmation.

Autre solution :un exemple que j'ai tres souvent pris dans l'enseignement :
imagine que tu doive coder "APPRENDRE" pour ton personnel !
en anglais aucun probleme, en tre TEACH et LEARN,
en francias, il faudra distinguer Eleve.Apprendre et Professeur.Apprendre...

Dans le cas particulier des Noms puisque c'etait ton exemple,
imagine que nous décidions de gérer les Noms avec un controle d'orthographe
et de formattage :
il suffit de rajouter dans le Set Nom le controle garantissant
automatiquement
la transformation des Espaces CHR(20) en CHR(255) pour avoir un format non
déformable, etc....

Je ne developpe pas plus ici, mais n'hesite pas a me poser d'autres
questions..
L'objet, c'est un peu mon dada, depuis 87, et malgré VB !

ydx35[NO_SAPM]at_YahOOOOOO.fr