Très intéressant et qui a surement demandé beaucoup de travail.

Un problème cependant, lorsqu'on drag and drop et que le n½ud visé est en haut et non visible, il n'y a pas de défilement vers le haut qui se produit.

Faire le test en réduisant la surface du Treeview.

Tu as bien raison, mais on fait ce qu'on peut.

Je ne suis pas un puriste du non goto, parce qu'une source peut devenir plus difficile à suivre à cause du ce purisme, et parce que du point de vue de l'efficacité et de la rapidité, un goto se traduit en assembler par une instruction, alors que d'autres formulations produisent plus d'une instruction, dans le cas d'un appel à une procédure ou une fonction, il y a tout le travail à l'aller et le retour pour sauver et restaurer les registres. S'interdire les goto, c'est contribuer à ce que les ordinateurs deviennent plus puissants, mais que les programmeurs les rendent moins efficaces.

Tant qu'un goto ne cause pas de problème de compréhension et est plus efficace, je m'y autorise et ne prévois pas devenir un puriste du non goto.

Merci, pour tes remarques.

Tu as raison, cela provient d'un oubli de nettoyage après des test pour essayer de faire fonctionner le WndProc dans la classe pour ne pas avoir à le refaire à chaque fois dans le formulaire principal de l'application mais cela ne semble pas fonctionner.

bigboss9 se complique beaucoup la vie en gardant des habitudes du VB6 et moins, car en .NET, il suffit de fonctionner en mode virtuel (VirtualMode) qui est disponible pour un Datagridview.

Le plus simple est de gérer les dossiers dans le DirExplorer, car le FileExplorer est un ListView et non pas une TreeView, ce qui rend la gestion des répertoires et des arborescences problématique.

Il y a la propriété 'FileExplorer.ShowFolders' qui lorsque à 'False', les répertoires ne sont alors pas affichés avec les fichiers dans le FileExplorer.

Pour Combo_1 et Combo_2, il s'agit des noms des colonnes (qui doivent être suivis de .name) dans le DataGridView, le premier pour la colonne qui correspond au Combobox1 et le deuxième pour Combobox2. On pourrait aussi utiliser l'Index de la colonne ou un autre nom de colonne, mais c'est plus facile de s'y retrouver avec des noms qui rappelle les liens entre la colonne et le combobox.

CrazyCow007 a raison pour le bug, le système n'envoie pas de message comme quoi la souris est sorti du cadre du combobox ou s'il perd le focus. Il faut ajouter des instructions ailleurs pour le rendre invisible.

Le code est minimal et non optimisé, il faut entre autre modifier la liste du deuxième combobox si le choix dans le premier est modifié, et vérifier qu'il y a bien un changement de sélection, car après qu'un déroulement se soit produit, l'événement SelectedIndexChanged se déclenche même si le même élément est sélectionné.

Je n'ai pas vu d'option dans VB 2008 Express pour exporter en VB 2005.

As-tu essayé de créer un nouveau projet en VB 2005, d'enlever le formulaire qui est mis par défaut pour ne pas qu'il y ait de conflit de nom, et d'ajouter le formulaire du démo. Il n'y a rien de spécifique à VB 2008 dans le source, ni dans les fichiers *.vb. Le fichier *.resx utilise Microsoft ResX Schema Version 2.0, mais j'ignore la version en VB 2005. Le problème semble provenir du fichier *.proj qui lui est créé par la version de VB.

Si cela ne fonctionne pas, laisse-moi savoir, je vais voir s'il y a une voie de contournement.

Pour que l'affichage des Combobox se positionne correctement, il faut additionner les valeurs de positionnement top et left du DataGridView, car la métrique retournée par le système du positionnement des cellules est relative au cadre du DataGridView, alors que le positionnement des Combobox est relative au cadre client du formulaire.