Problème Visual Studio 2008 Express
Redman31100
Messages postés
167
Date d'inscription
mardi 11 septembre 2007
Statut
Membre
Dernière intervention
11 février 2009
-
5 févr. 2009 à 09:19
Londonic Messages postés 298 Date d'inscription jeudi 22 janvier 2009 Statut Membre Dernière intervention 26 septembre 2009 - 3 mars 2009 à 22:09
Londonic Messages postés 298 Date d'inscription jeudi 22 janvier 2009 Statut Membre Dernière intervention 26 septembre 2009 - 3 mars 2009 à 22:09
1 réponse
Londonic
Messages postés
298
Date d'inscription
jeudi 22 janvier 2009
Statut
Membre
Dernière intervention
26 septembre 2009
3 mars 2009 à 22:09
3 mars 2009 à 22:09
Moi aussi, j'ai vu disparaître des objets du concepteur, et ils reviennent pas toujours quand on re-initialise le projet.
J'ai vite appris a refaire le code dans le concepteur, mais c'est pas toujours trés clair. (C'est le concepteur qui est pas clair, et il aime pas trop quand on change les étiquettes)
Je n'ai plus aucun problème depuis que je déclare tous les contrôles dans le code, et ça m'oblige à garder un meilleur équilibre entre une interface trop facile à décrire et un code encore très dichotomique. Sans compter que c'est plus difficile de placer la déclaration en dehors du code que le Client en dehors de son Parent.
Je conserve encore la première page (Form1), mais comme tous les contrôles y sont Add Dans le texte, le code du concepteur est réduit au minimum, et c'est toujours le même.
Cependant, et pour obéïr à la grosse fenêtre d'injonction de l'edi qui recommande tout mais pas ça, je m'initie au WPF qui interprète le code de conception visuelle pour afficher l'application au fur et à mesure.
Je voulais me passer de ce code pour développer plus classique, et je me suis apperçu qu'on peut très bien écrire un programme en basic WPF comme si c'était du 6. Il faut juste développer quelques objets fondamentaux d'interface en plus, mais ça redevient du Pascal : L'interprèteur n'assume plus.
En définitive, le basic classique reste une aubaine pour les ASMs qui veulent concocter un gros pupitre pour leurs petits paramètres. Il me semble qu'on cherche plutot le contraire: allèger l'interface avec du code.
Salut @+, en espèrant que la mémoire d'écran est pas dans le noyau protégé, sinon j'oublie tous les basics du siècle dernier et je démarre le calendrier en 2008.
J'ai vite appris a refaire le code dans le concepteur, mais c'est pas toujours trés clair. (C'est le concepteur qui est pas clair, et il aime pas trop quand on change les étiquettes)
Je n'ai plus aucun problème depuis que je déclare tous les contrôles dans le code, et ça m'oblige à garder un meilleur équilibre entre une interface trop facile à décrire et un code encore très dichotomique. Sans compter que c'est plus difficile de placer la déclaration en dehors du code que le Client en dehors de son Parent.
Je conserve encore la première page (Form1), mais comme tous les contrôles y sont Add Dans le texte, le code du concepteur est réduit au minimum, et c'est toujours le même.
Cependant, et pour obéïr à la grosse fenêtre d'injonction de l'edi qui recommande tout mais pas ça, je m'initie au WPF qui interprète le code de conception visuelle pour afficher l'application au fur et à mesure.
Je voulais me passer de ce code pour développer plus classique, et je me suis apperçu qu'on peut très bien écrire un programme en basic WPF comme si c'était du 6. Il faut juste développer quelques objets fondamentaux d'interface en plus, mais ça redevient du Pascal : L'interprèteur n'assume plus.
En définitive, le basic classique reste une aubaine pour les ASMs qui veulent concocter un gros pupitre pour leurs petits paramètres. Il me semble qu'on cherche plutot le contraire: allèger l'interface avec du code.
Salut @+, en espèrant que la mémoire d'écran est pas dans le noyau protégé, sinon j'oublie tous les basics du siècle dernier et je démarre le calendrier en 2008.
