Extension d'ExplorerBrowser à partir du Pack de code API Windows pour afficher les fichiers autres que des fichiers de fichiers

Question

J'écris un programme WPF en C# qui doit restituer un ensemble de fichiers dans un navigateur de fichiers à l'utilisateur final. Le contrôle ExplorerBrowser trouvé à l'intérieur du Microsoft Windows API CodePack contient la plupart des fonctionnalités dont j'ai besoin ... par ex. Les vignettes de différentes tailles, le tri, la navigation, etc ...

Le problème est que les fichiers ne proviennent pas du disque, mais sont disponibles via un protocole de transfert réseau personnalisé. Je pensais à l'origine que je pouvais simplement étendre la classe ShellObjectContainer et les classes ShellObject pour fournir les fonctionnalités dont j'ai besoin, en construisant essentiellement un adaptateur. Cependant, j'ai rencontré des difficultés car ces classes utilisent des constructeurs internes. Dans l'ensemble, il semble que cette API soit plutôt hostile à l'extension, est-il possible d'étendre ces composants pour faire ce dont j'ai besoin, ou est-il préférable de reconstruire beaucoup de fonctionnalités ExplorerBrowsers en créant un composant WPF personnalisé, peut-être en étendant ListBox?

Answer 1

Oui, cela n'a certainement pas été fait pour être extensible. Difficile de voir comment vous pourriez obtenir n'importe où, sauf si vous créez votre propre extension de l'espace de noms de shell. Alors que c'est visible dans une fenêtre shell. Cela est assez brutal dans le code managé, les interfaces COM du shell dérivées de IUnknown sont très difficiles à utiliser. C'est ce que font les classes wrapper dans le pack de code API pour obtenir une fenêtre de navigateur dans un programme géré.

La création de l'extension de l'espace de noms du shell est la meilleure solution, vos fichiers personnalisés sont également visibles dans une fenêtre de l'explorateur classique. Mais écrivez ce type de code en C++, à la fois parce qu'il est beaucoup plus facile d'obtenir le code COM et d'éviter d'injecter le CLR dans un programme utilisant une boîte de dialogue Fichier + Ouvrir. Bien que cela soit maintenant techniquement supporté par .NET 4.0