Je n'irais pas sur la méthode d'instanciation de 45 formulaires au démarrage de l'application. Cela augmenterait considérablement le temps de démarrage et, si ce n'est probablement, épuiserait vos ressources mémoire, pour fournir des fonctionnalités dont votre utilisateur n'a peut-être même pas besoin.
Dans mes applications WinMo, chaque formulaire est conçu pour fonctionner avec un sous-ensemble de données relativement petit. Le temps de démarrage est donc limité aux appels de base de données et au chargement des données dans les contrôles du formulaire. Généralement, le temps requis pour instancier l'une de ces formes et montrer qu'il n'est jamais plus d'une seconde ou deux. Si vos formulaires sont plus longs à afficher, il est possible que votre récupération de données ou la façon dont les données sont chargées dans les contrôles du formulaire posent un problème (par exemple, vous pouvez avoir un contrôle gridview personnalisé qui rend entièrement 300 lignes même si seulement 12 sont visibles en même temps). Si vos données sont si volumineuses qu'elles prennent légitimement beaucoup de temps à être récupérées, il y a de fortes chances que ce soit beaucoup plus de données qu'un utilisateur puisse pratiquement interagir de toute façon.
Je suppose que votre mention de "5 sections" pour obtenir où l'utilisateur doit aller signifie qu'ils pourraient (au maximum) être "percer" 5 niveaux à quelque chose. Si vous implémentez cela en faisant instancier chaque formulaire et que vous affichez le formulaire suivant en utilisant ShowDialog, vous auriez au maximum 5 à 6 formulaires existant à la fois, ce qui ne devrait poser aucun problème pour une application .Net CF (je fais ceci tout le temps). De cette façon, vous n'avez rien de spécial à faire pour savoir quel formulaire doit être affiché lorsque - vous ouvrez simplement un formulaire depuis n'importe où, et lorsque le formulaire est fermé, vous revenez automatiquement au formulaire d'appel.
Il y a une certaine bizarrerie de z-order/task manager que vous avez à traiter, mais ce n'est pas particulièrement compliqué. Avant d'appeler le ShowDialog sur le formulaire enfant, définissez la propriété Text du formulaire parent sur une chaîne vide, puis redéfinissez-la sur la légende d'origine du formulaire après les retours ShowDialog. Ce n'est pas strictement nécessaire, mais dans Windows Mobile (au moins jusqu'à la version 6) tous les formulaires .Net ouverts (avec une propriété Text non vide) apparaissent dans la liste des programmes en cours d'exécution, même s'ils proviennent tous du même application. En général, j'aime que mes applications multi-formulaires apparaissent comme un seul programme, donc je règle généralement le Text de chaque formulaire au nom de l'application).
J'ai également expérimenté avec une application à formulaire unique qui implémente chaque élément de l'interface utilisateur en tant que UserControl au lieu d'un formulaire, puis crée et empile les contrôles comme si vous créiez et ouvriez des formulaires. Cela fonctionne mais c'est un hack et je ne le recommande pas. Les formulaires ont un événement Load et UserControls non, ce qui constitue le problème principal.
Ah, mais si vous utilisez un framework autour de ces UserControls, vous pouvez créer votre propre événement Load. – ctacke
Bah, je n'utilise même plus de * contrôles * - je viens juste de "BitBlt" à l'écran. :) – MusiGenesis
Oh, j'ai un formulaire avec 47 UserControls pour les vues. Mais la chose intéressante est que j'ai un seul contrôle personnalisé qui est utilisé pour afficher * chaque * élément d'interface utilisateur sur chaque vue. Pour obtenir l'alphablending dont j'avais besoin, je me suis contenté de faire un "swiss army swiss", de l'assembler avec de la peinture personnalisée et d'abandonner tout le reste dans la boîte à outils. Ah les joies du développement des FC. – ctacke