OVH Cloud OVH Cloud

événement Quitter d'une application

16 réponses
Avatar
Christian
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=false donc là : End (ça ça va)
End If

End Sub

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

Encore meeeerrciiiiiiiii !

6 réponses

1 2
Avatar
christophe-pasde
>
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 !




Bonjour,

Alors va voir ça si tu connais pas déjà l'adresse
http://ftp.lami.univ-evry.fr/pub/specif/fzaidi/UML%20pam.pdf

La version 2.0 est dispo en librairie.
J'ai lu ça il y a pas longtemps et ça change radicalement la façon de
voir les choses.


Christophe
Avatar
Patrice Henrio
Merci du lien.
Ca a l'air effectivement alléchant.

"christophe-pasde<> @wanadoo.fr>" <"christophe-pasde<> a écrit dans le
message de news: 41764ab3$0$28781$


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 !




Bonjour,

Alors va voir ça si tu connais pas déjà l'adresse
http://ftp.lami.univ-evry.fr/pub/specif/fzaidi/UML%20pam.pdf

La version 2.0 est dispo en librairie.
J'ai lu ça il y a pas longtemps et ça change radicalement la façon de voir
les choses.


Christophe


Avatar
Patrice Henrio
Je suis d'accord pour la plupart des méthodes, type print, somme ou autre
mais pour l'accès aux propriétés, je ne comprends pas en quoi <Objet>.name =
"toto" protège plus l'objet s'il s'agit d'une propriété gérée par set et get
plutôt que d'une variable privée.


"YannX" a écrit dans le message de news:


"Patrice Henrio" a écrit dans le
message de news:


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





Avatar
YannX
"Patrice Henrio" a écrit dans le message de
news:
Je suis d'accord pour la plupart des méthodes, type print, somme ou autre
mais pour l'accès aux propriétés, je ne comprends pas en quoi <Objet>.name


> "toto" protège plus l'objet s'il s'agit d'une propriété gérée par set et
get
plutôt que d'une variable privée. de l'usage



deux niveaux de reponses :
- passer par des methodes plutot que directement la variable permet
de choisir l'implementation independanment de l'usage (un exemple:
comment implementer une date-heure :
- au format classique ( 6 entiers), ou comme Excel/Access
- comme un réel (comme Excel/Access)
(et avec quelle origine = cf. An 2000)

- faciliter les controles garantis :
comment eviter de rentrer en direct la date
30/02/2003 24:79:99 (qui cumule toutes les erreurs ou presque ?)

Avec une fonction a passage obligatoire, aucun probleme,
l'implementation est libre.....et independante du programme utilisateur !

C.Q.F.D.

Yan



"YannX" a écrit dans le message de news:

>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> 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
>
>
>




Avatar
Patrice Henrio
Je crois après plusieurs réflexion avoir enfin compris l'intérêt des
méthodes même dasn le cas d'un set qui se contente de recopier dans une
variable privée la valeur d'un paramètre.
Je pense que si on modifie certains aspects de la classe qui nécessite que
l'affectation d'une valeur soit modifiée, on n'a besoin de ne modifier que
la classe elle-même au lieu d'avoir à récupérer toutes les affectations qui
se trouvent dans le projet.
Je crois que c'est ce que tu voulais dire par indépendance du code.
Merci en tout cas de ces infos.
"YannX" a écrit dans le message de news:


"Patrice Henrio" a écrit dans le
message de news:


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





Avatar
YannX
Affirmatif !
Pendant qu'on y est, que VB 6 est mal foutu à cet égard !
Dommage que VB.NET ne soit pas encore intégré à Office !

Mais VB et la compilation modulaire = contradiction totale !

Dommage

YannX (un ancien du C++)

"Patrice Henrio" a écrit dans le message de
news:
Je crois après plusieurs réflexion avoir enfin compris l'intérêt des
méthodes même dasn le cas d'un set qui se contente de recopier dans une
variable privée la valeur d'un paramètre.
Je pense que si on modifie certains aspects de la classe qui nécessite que
l'affectation d'une valeur soit modifiée, on n'a besoin de ne modifier que
la classe elle-même au lieu d'avoir à récupérer toutes les affectations


qui
se trouvent dans le projet.
Je crois que c'est ce que tu voulais dire par indépendance du code.
Merci en tout cas de ces infos.
"YannX" a écrit dans le message de news:

>
> "Patrice Henrio" a écrit dans le
> message de news:
>
>>
>> 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
>
>
>




1 2