Discussion :

[Kropernic]

Hello,

Ca à l'air tout con mais je tente de fermer l'application dans le constructeur du premier formulaire sans succès...

Par exemple, si un utilisateur inconnu démarre l'application, j'affiche le message adéquat et je veux fermer l'application juste après.

Bin pas moyen... J'ai le message suivant :

Une erreur s'est produite lors de la création du formulaire. Pour plus d'informations, consultez Exception.InnerException.

Et ça, je le savais déjà. C'est bien pour ça que je souhaite fermer l'application .

J'ai essayé le Me.Close(), le Me.Dispose() et j'ai aussi levé une exception pour utiliser l'événement d'application UnhandledException mais j'ai l'impression que ça ne rentre même pas dans cet event...

J'ai bien pensé à un contournement en utilisant un flag pour savoir s'il faut fermer et faire le check et le close dans l'event Load du formulaire mais ça ne me parait pas super propre...

Des idées ?

Est-il possible que l'utilisation des événements d'application ne fonctionne pas dans VS (ni en débug, ni en release) ?

Car si je vais dans le folder et que je run l'exe, là j'ai bien mon message d'erreur et tout et tout...

[jopopmk]

Salut,

je sais que pour les dev ASP.NET c'est un IIS spécial qui est lancé depuis VS.
Est-ce qu'une CLI particulière est également utilisée ? Aucune idée, mais ça m'étonnerait.

Pour en revenir à ton problème : c'est le fait que l'utilisateur soit inconnu qui engendre le plantage, ou tes tentatives de fermer l'appli dans ce cas là ?
Ne serait-il pas possible de faire la vérif' dans le point d'entrée, avant même de construire ton premier formulaire ?

[wallace1]

Bonsoir Kropernic,

Un problème qui devrait te conduire incessamment sous peu à mettre en place un Sub Main qui se chargera de lancer ultérieurement ton Main Form

J'en parle ici : http://www.developpez.net/forums/d13...a/#post7534621

PS : en procédant ainsi tu n'as pas besoin d'agir sur une quelconque fermeture d'application dans le constructeur de ton main form (ce qui n'est au final pas très logique comme comportement) !

Si tu veux des éclaircissements, je suis ton homme.

[Kropernic]

Déjà, merci à tous les deux pour la réponse.

j'arrive maintenant à plutôt de détruire l'objet dans le constructeur, généré une exception que je ne gère pas pour passer dans les appevents et là, je peux gérer l'exception et fermer l'application.

Cependant, le coup du sub main m'a l'air pas mal. J'y regarderai demain

[jopopmk]

Y'a pas de Main (point d'entrée) par défaut dans un programme VB.NET ?

[Sankasssss]

Bonjour vous deux,

@wallace1 : j'ai un problème avec cette méthode de démarrage sur sub Main que j'ai utilisée fort longtemps avant de me servir des événements de l'application.
En effet, depuis un moment, comme Kropernic j'utilise, entre autre, l’événement d'application UnhandledException pour loguer toutes les erreurs non gérée de l'application (Si on attend de l'utilisateur de nous remonter les bugs on peut attendre longtemps chez nous).
Malheureusement en utilisant le démarrage sur Sub Main, on doit désactiver l'infrastructure d'application et donc les événements de l'application ne sont plus disponible.

J'ai pas encore pris le temps de chercher si ces différents événements d'application étaient disponible d'une autre manière, si tu as une piste n'hésite pas...

Y'a pas de Main (point d'entrée) par défaut dans un programme VB.NET ?

Par défaut, pour une application WindowsForm, VS est réglé sur "Infrastructure d'application" qui le fait démarré sur un formulaire (Form1).
Mais on peut revenir à un comportement plus conventionnel en le réglant manuellement dans les propriétés de l'application (Projet => Propriétés de ...)

[jopopmk]

Merci pour l'info, j'ai pas fait de VB depuis un bail, j'ai un peu oublier le fonctionnement

[wallace1]

Bonjour vous deux,

@wallace1 : j'ai un problème avec cette méthode de démarrage sur sub Main que j'ai utilisée fort longtemps avant de me servir des événements de l'application.
En effet, depuis un moment, comme Kropernic j'utilise, entre autre, l’événement d'application UnhandledException pour loguer toutes les erreurs non gérée de l'application (Si on attend de l'utilisateur de nous remonter les bugs on peut attendre longtemps chez nous).
Malheureusement en utilisant le démarrage sur Sub Main, on doit désactiver l'infrastructure d'application et donc les événements de l'application ne sont plus disponible.
J'ai pas encore pris le temps de chercher si ces différents événements d'application étaient disponible d'une autre manière, si tu as une piste n'hésite pas...

Bonjour Sankasssss,

Effectivement, dès lors que nous décochons la case "Infrastructure d'application" nous devons nous abonner manuellement aux événements d'application dont nous avons besoin.
A ce titre je pense qu'il est possible de s'abonner au gestionnaire d'évènement "UnhandledException" de cette manière dans le Sub main :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 AddHandler System.AppDomain.CurrentDomain.UnhandledException, AddressOf .........

..... comme on pourrait le faire avec les autres événements que tu souhaites utiliser ultérieurement.

@Kropernic : il existe une autre manière d'agir dans le point d'entrée de l'appli avant que le formulaire principal ne s'affiche en passant par les événements d'application comme mentionné par Sankasssss :

https://msdn.microsoft.com/en-us/lib...(v=vs.90).aspx

[Kropernic]

C'est quand même marrant la manière dont on parvient à faire des associations logiques parfois et parfois pas.

Ca fait bien 2 ans que j'utilise l'appevent UnhandledException (pour la même raison que sankassss) et jamais il ne m'a traversé l'esprit qu'il pourrait y en avoir d'autres qui seraient utiles...

Du coup, mon regard se tourne maintenant vers l'event Startup qui m'a tout l'air d'être l'endroit idéal pour faire tous les tests permettant de savoir si l'utilisateur à le droit d'utilisation l'application.
Du coup, je me demande si je peux m'occuper de la construction du premier formulaire moi-même dans cet event histoire de lui passer, par exemple, l'objet métier User que j'utilise à travers toute l'application.

Actuellement, cet objet est créé dans le constructeur du premier formulaire. Avec le startup, j'aimerais autant le passer en paramètre. Niveau exemple, la MSDN est assez avare pour le coup. Et j'ai l'impression que c'est mort car même si je peux instancier un formulaire et l'afficher dans cet event, une fois que je le ferme, alors l'application démarre et le formulaire revient XD.

En fait, je peux créer un objet user et faire les tests que je dois faire pour valider l'utilisation ou non mais je trouve ça dommage de créer l'objet juste pour ça et de récréer le même dans le formulaire après alors qu'il pourrait juste utiliser le même...

[jopopmk]

Tu pourrais instancier ton user en global (en static dans une class static public pour faire joli par exemple).
Si la "connexion" est valide ton Form utilse ce même objet, sinon tu fais un Environment.Exit(-1) (ou n'importe quel code différent de zéro).