Programmation VB 2008: controler le déroulement du projet
cs_inforom
Messages postés
36
Date d'inscription
mercredi 8 octobre 2008
Statut
Membre
Dernière intervention
12 avril 2017
-
21 déc. 2009 à 20:55
cs_inforom Messages postés 36 Date d'inscription mercredi 8 octobre 2008 Statut Membre Dernière intervention 12 avril 2017 - 27 déc. 2009 à 11:27
cs_inforom Messages postés 36 Date d'inscription mercredi 8 octobre 2008 Statut Membre Dernière intervention 12 avril 2017 - 27 déc. 2009 à 11:27
A voir également:
- Programmation VB 2008: controler le déroulement du projet
- Vb vba - Forum VB.NET
- Vb access - Conseils pratiques -Visual Basic / VB.NET
- C to vb ✓ - Forum VB.NET
- Vb net sleep ✓ - Forum Visual Basic
- Msgbox vb - Conseils pratiques -Visual Basic / VB.NET
4 réponses
PCPT
Messages postés
13272
Date d'inscription
lundi 13 décembre 2004
Statut
Membre
Dernière intervention
3 février 2018
47
22 déc. 2009 à 01:01
22 déc. 2009 à 01:01
salut,
umm, çà dépend là, c'est assez vague....
si tes écrans (forms) sont à TON regard plus ou moins pour la même application, il y a des chances que tes bibliothèques aussi.
du coup "plusieurs bibliothèques" ne sont pas utiles : soit 1, soit aucune
de là tu peux
mettre toutes tes forms et tes class dans le même projet (application winforms)
mettre toutes tes forms dans un projet, et tes class dans un second, assembly ( = bibliothèque de classes)
si au contraire tu penses que ton application finale est plutôt une sorte de... concentrateur d'actions et ou d'écrans (je sais pas comme... disons la sidebar de vista : la barre d'un côté et chaque élément distinct indépendant mais fonctionnant avec la barre), alors un projet principal (genre la barre), et autant de projets que d'éléments, qui seront alors sans doute plutôt des bibliothèques de contrôles winforms contenant également leurs classes respectives
ton application sera alors en charge de la coordination de chacun des éléments et instanciera chaque "contrôle" dynamiquement
très bien de penser aussi à cet aspect, bravo !
bon courage
[hr]
umm, çà dépend là, c'est assez vague....
si tes écrans (forms) sont à TON regard plus ou moins pour la même application, il y a des chances que tes bibliothèques aussi.
du coup "plusieurs bibliothèques" ne sont pas utiles : soit 1, soit aucune
de là tu peux
mettre toutes tes forms et tes class dans le même projet (application winforms)
mettre toutes tes forms dans un projet, et tes class dans un second, assembly ( = bibliothèque de classes)
si au contraire tu penses que ton application finale est plutôt une sorte de... concentrateur d'actions et ou d'écrans (je sais pas comme... disons la sidebar de vista : la barre d'un côté et chaque élément distinct indépendant mais fonctionnant avec la barre), alors un projet principal (genre la barre), et autant de projets que d'éléments, qui seront alors sans doute plutôt des bibliothèques de contrôles winforms contenant également leurs classes respectives
ton application sera alors en charge de la coordination de chacun des éléments et instanciera chaque "contrôle" dynamiquement
très bien de penser aussi à cet aspect, bravo !
bon courage
[hr]
cs_inforom
Messages postés
36
Date d'inscription
mercredi 8 octobre 2008
Statut
Membre
Dernière intervention
12 avril 2017
22 déc. 2009 à 07:26
22 déc. 2009 à 07:26
Merci de ta réponse ... et de tes encouragements, mais je reste en suspens tout de même.
Mon application n'est pas particulièrement complexe: c'est pour l'administration de dossiers de gestion, le 'corps' de l'application étant constitué de classeurs EXCEL entièrement programmés (on a choisi excel car le contenu, sur le plan du traitement, est essentiellement basé sur des calculs 'background').
A chaque dossier est associée une base de données (MySQL), avec une base de référence qui est distincte selon qu'on travaille en DEMO ou non.
J'ai donc créé une form 'Login' qui détermine la base de référence et contrôle l'accés (code utilisateur et mot de passe) et deux forms préfigurant les diverses fonctionnalités à proposer (pour la gestion des dossiers et des utilisateurs). La bibliothèque de classes contient deux classes (une qui correspond à la connection à la base de référence et l'autre qui permet de naviguer dans les structures).
J'ai intégré la bibliothèque en tant que référence, pour le projet, et ça fonctionne très bien: les forms créent les objets nécessaires à partir des classes de la bibliothèque et disposent directement des méthodes et propriétés exposées.
Le projet principal est donc de type WindowsForms. Ce qui me bloque c'est que je ne sais pas où placer le code d'initialisation, qui va lancer le login, puis, selon le résultat, ouvrir telle ou telle fenêtre.
Il me faut au minimum des variables publiques visibles dans tout le projet et à indépendantes des forms, et une procédure principale pour enchainer les appels. J'ai essayé de déclarer une variable publique au niveau de l'événement 'startup' de l'application : elle n'est même pas visible dans la fenêtre 'login'.
J'imagine que je peux m'en tirer en associant une première fenêtre au projet, puis de tout coder dans le corps de cette classe, en supposant que je pourrais la masquer pendant l'exécution des forms secondaires, mais je me dis qu'il doit bien y avoir la possibilité de créer une procédure principale (je ne sais pas.. un truc du type 'Main', ou 'Code du projet'... ).
Ce doit bien être une question de débutant, même si par ailleurs je maitrise assez bien la programmation. Mes premiers codes en Basic datent de plus de 30 ans, mais c'est la première fois que je manipule un produit de développement Microsoft.. Par ailleurs, moi qui adore 'bidouiller', je me suis juré que pour le moment je devais rechercher les solutions 'standard' (bientot un jeune prendra ma place...).
@+
InfOrom
Mon application n'est pas particulièrement complexe: c'est pour l'administration de dossiers de gestion, le 'corps' de l'application étant constitué de classeurs EXCEL entièrement programmés (on a choisi excel car le contenu, sur le plan du traitement, est essentiellement basé sur des calculs 'background').
A chaque dossier est associée une base de données (MySQL), avec une base de référence qui est distincte selon qu'on travaille en DEMO ou non.
J'ai donc créé une form 'Login' qui détermine la base de référence et contrôle l'accés (code utilisateur et mot de passe) et deux forms préfigurant les diverses fonctionnalités à proposer (pour la gestion des dossiers et des utilisateurs). La bibliothèque de classes contient deux classes (une qui correspond à la connection à la base de référence et l'autre qui permet de naviguer dans les structures).
J'ai intégré la bibliothèque en tant que référence, pour le projet, et ça fonctionne très bien: les forms créent les objets nécessaires à partir des classes de la bibliothèque et disposent directement des méthodes et propriétés exposées.
Le projet principal est donc de type WindowsForms. Ce qui me bloque c'est que je ne sais pas où placer le code d'initialisation, qui va lancer le login, puis, selon le résultat, ouvrir telle ou telle fenêtre.
Il me faut au minimum des variables publiques visibles dans tout le projet et à indépendantes des forms, et une procédure principale pour enchainer les appels. J'ai essayé de déclarer une variable publique au niveau de l'événement 'startup' de l'application : elle n'est même pas visible dans la fenêtre 'login'.
J'imagine que je peux m'en tirer en associant une première fenêtre au projet, puis de tout coder dans le corps de cette classe, en supposant que je pourrais la masquer pendant l'exécution des forms secondaires, mais je me dis qu'il doit bien y avoir la possibilité de créer une procédure principale (je ne sais pas.. un truc du type 'Main', ou 'Code du projet'... ).
Ce doit bien être une question de débutant, même si par ailleurs je maitrise assez bien la programmation. Mes premiers codes en Basic datent de plus de 30 ans, mais c'est la première fois que je manipule un produit de développement Microsoft.. Par ailleurs, moi qui adore 'bidouiller', je me suis juré que pour le moment je devais rechercher les solutions 'standard' (bientot un jeune prendra ma place...).
@+
InfOrom
PCPT
Messages postés
13272
Date d'inscription
lundi 13 décembre 2004
Statut
Membre
Dernière intervention
3 février 2018
47
22 déc. 2009 à 13:06
22 déc. 2009 à 13:06
une sub Main oui, dans un module
cette Main te sera alors proposée dans les propriétés du projet winforms
ensuite une classe clsUser, avec Login et password et... ce que tu veux en rapport
une variable cUser public dans le module
le Main va ouvrir ta frmLogin et attribuer le résultat à cUser
la suite de ton code (sans doute le chargement et affichage de ta 2e form) à la suite de cette action dans le main
cette 2e form aura alors accès à cUser qui aura les valeurs qui viennent d'être saisies
++
cette Main te sera alors proposée dans les propriétés du projet winforms
ensuite une classe clsUser, avec Login et password et... ce que tu veux en rapport
une variable cUser public dans le module
le Main va ouvrir ta frmLogin et attribuer le résultat à cUser
la suite de ton code (sans doute le chargement et affichage de ta 2e form) à la suite de cette action dans le main
cette 2e form aura alors accès à cUser qui aura les valeurs qui viennent d'être saisies
++
cs_inforom
Messages postés
36
Date d'inscription
mercredi 8 octobre 2008
Statut
Membre
Dernière intervention
12 avril 2017
27 déc. 2009 à 11:27
27 déc. 2009 à 11:27
Merci PCPT...
C'était bien le type d'info que je désirais....
J'ai du chercher pour implanter la solution, et je me permets donc de rajouter, à l'attention de ceux qui auraient le même problème que moi:
- en choisissant un projet de type WinForms, je pense que VB génère lui-même un 'squelette' qui commence par ouvrir la boite de dialogue définie dans 'Objet de démarrage' et qui ne propose que la liste des formulaires présents dans le projet (voir dans 'Propriétés du projet').
- Pour contrôler soi-même le déroulement du 'programme', il faut décocher l'option 'Activer l'infrastructure de l'Application', ce qui permet alors, dans les 'objets de démarrage', de sélectionner 'Sub Main'.
- Pour écrire la procédure Main() il faut ajouter un module au projet, dans lequel on pourra définir la procédure Main et programmer tout ce qu'on veut faire...
- autre info pour les débutants venant du VBA comme moi: la méthode Show, pour une boite de dialogue, correspondant à une ouverture 'NON MODALE': utiliser 'ShowDialog' pour une ouverture modale...
A bientot
InfOrom
C'était bien le type d'info que je désirais....
J'ai du chercher pour implanter la solution, et je me permets donc de rajouter, à l'attention de ceux qui auraient le même problème que moi:
- en choisissant un projet de type WinForms, je pense que VB génère lui-même un 'squelette' qui commence par ouvrir la boite de dialogue définie dans 'Objet de démarrage' et qui ne propose que la liste des formulaires présents dans le projet (voir dans 'Propriétés du projet').
- Pour contrôler soi-même le déroulement du 'programme', il faut décocher l'option 'Activer l'infrastructure de l'Application', ce qui permet alors, dans les 'objets de démarrage', de sélectionner 'Sub Main'.
- Pour écrire la procédure Main() il faut ajouter un module au projet, dans lequel on pourra définir la procédure Main et programmer tout ce qu'on veut faire...
- autre info pour les débutants venant du VBA comme moi: la méthode Show, pour une boite de dialogue, correspondant à une ouverture 'NON MODALE': utiliser 'ShowDialog' pour une ouverture modale...
A bientot
InfOrom
