Oui je comprend bien où tu as voulu allez, c'est sure que quand une "entité" externe controle le comportement de l'application, elle est plus puissante.
Mais tu as des choses qui restent fixent. Comme le Show, le name etc.

Sans regarder ta table je serais partie sur un système où une ligne correspond à un objet possible, ensuite je met en colonne la method_name à appeler quand on clic sur le menu et une initialisation des propriétés en colonnes pour tous les objets
Tu obtiens ainsi une table de menu qui appel des objet par leur nom (TypeOf via réflexion)+nom de la méthode init et une table des objets/interface avec leur propriétés par défaut à l'init en colonne. Tu obtiens ainsi le menu xyz qui lance la fenêtre ABC qui fait partie de l'interface ZZ dont la ligne dans la table détermine que pour cette interface là la propriété readonly est mise à true... après tu peux ajouter le nom de l'objet plutôt que l'interface pour détacher ton objet de ton interface et le rendre ainsi non pas enfant de l'interface mais défini à coté.

Je sais pas si tout ça est très clair, car ce n'est qu'un jet sur le dynamisme SQL/C# mais ça te permet de jouer avec des objets connu dans ton environement tout en jouant avec des variables d'environnement.

Merci pour le partage, car on a rarement des applications complètent de ce genre.
Cependant je suis sceptique quand aux "bonnes pratiques", car tu aurais due utiliser des interfaces sur tes objets forms, ce qui t'aurais permis de ne pas faire de réflexion sur tes objets et te demander si la propriété, méthode ou autre existe dans l'objet.
Le code est plus propre, plus évolutif et plus compréhensible surtout... ou alors j'ai rien compris au code démo.

Très bon code. Il manque cependant une classe intermédiaire d'interprétation, comme on travaille en "string" qui permettrait de passer des objets plus complexe.
Y'a de l'idée ;)

Le must aurait été d'enregistrer les informations pour sortir des feuilles de prestations ;)

Oui bien entendu mais si tu programme dans l'idée que toi seul maintiendra ton code, tu verra quand tu aura 50 projet derrière toi, tu ne comprendra plus tes premiers codes, car ta technique aura évolué, les noms que tu utilisera, etc. Si tu ne perd pas ton temps au départ, c'est les temps que tu perdra après pour maintenir ton code. Si dans optique de départ tu commente, tu structure avec l'idée de "est-ce que je peux le réutiliser plutard", si oui "est-ce que je peux le rendre plus puissant par la suite"... alors tu as tout compris, car la maintenabilité n'a pas de prix!
rdv dans 10 ans ? ;)

lol presque language humain... perso je suis prof de programmation on me sort un code comme ça je met 0, car la logique est dans ta tête. Une personne qui lit ça de haut en bas, comprend rien à ton code, il faut analyser chaque segment, chaque fonction pour se dire "ahhh ouiii mais bien sûre c'est comme ça qu'il a pensé là chose". Si je devais prendre le problème dans un texte en français, j'ai aucune intro et aucune conclusion, on ne connait ni là où ça commence (construction du bloc et l'addition des blocs) et pas de conclusion (que se passe t-il après qu'il ai mangé et comment les choses sont painte)... Je sais pas si tu vois où je veux en venir... Mais tu n'as pas de bloc logique dans le code. Tu vois des imbrications, mais pas de "trunk".
Aucun programmeur ne va encapsuler une classe faisant "pouette, pouette" dans la classe principale faisant le calcul. Bien sûre ta technique est bonne pour construire, conduire, etc. le serpent, mais la méthodologie est trop "simpliste" et donc presque inmaintenable. Je ne le conseillerais pas au débutant.
Parfois en programmation il faut faire plus de lignes pour rendre les choses plus simple, même si il y avait un chemin extrement plus court.
Pour moi en voyant une ligne comme ça dans mon code, je la delete et je la retravaille : if (Coordonates.Equals(Head)) Application.Exit(); else if( PreviousPiece != null) PreviousPiece.BitItSelf(Head);
En gros là on dit, ahhh il risque d'avoir un problème là, si y'a un problème "fuyons", elle est où la logique pour qu'un tel process n'arrive jamais?
PS : aucune attaque personnel dans ce message, rien qu'une critique de quelqu'un qui programme depuis de nombres années pour des entreprises ;)

Je vois pas en quoi ton code aide les débutant, y'a pas de avant-après, ni d'algorithme pour savoir comment ça fonctionne. Et je doute qu'un débutant puisse s'y retrouver dans ton code car il n'y aucun commentaire et certaines instructions sont sur la même ligne, ce qui est "nul" à part si on veut faire dans la figuration.
J'ai peine à croire qu'il sagit là d'un code enrichissant sur comment simplifié des codes complexes.
Excuse moi ton code est peut être "génial" mais un peu de modestie n'aurait pas fait de mal ;)

ouchh le vieux post ^^ je doute que tu y trouve ton bonheur mais bon... pour la dll tu dois installer le package VB6 disponible chez Microsoft.

En SQL 2005 (2008):

1) nom des tables : Select Name from dbo.sysobjects where xtype = 'U' order by Name
2) nom des champs : select sc.Name from dbo.sysobjects so inner join dbo.syscolumns sc on sc.id = so.id where so.name = 'Table'

Mais il me semble qu'il y a une Fonctions c# qui permet de récupéré tout ça, mais je ne reviens plus dessus.

hey hey y'a des idées interressantes ici... je répondrais à weabow en disant que lire oui, c'est écrire en cours d'utilisation qui sera impossible. Le mieux serait d'utiliser un boot-loader qui lui pourrait modifier l'application avant le démarrage de celle-ci...