从 Windows API 代码包扩展 ExplorerBrowser 以显示非文件系统文件
我正在用 C# 编写一个 WPF 程序，需要在文件浏览器中向最终用户呈现一组文件。 Microsoft Windows API CodePack 中的 ExplorerBrowser 控件包含我需要的许多功能...例如不同大小的缩略图、排序、浏览等...
问题是这些文件不是来自磁盘，而是通过自定义网络传输协议提供。
我最初认为我可以简单地扩展 ShellObjectContainer 类和 ShellObject 类来提供我需要的功能，本质上是构建一个适配器。然而，我遇到了困难，因为这些类使用内部构造函数。
总的来说，这个 API 看起来对扩展相当不利，有没有办法扩展这些组件来完成我需要的事情，或者我是否可以通过创建自定义 WPF 组件（也许通过扩展 ListBox）更好地重建 ExplorerBrowsers 的大部分功能？
I'm writing a WPF program in C# that needs to render a set of files in a file browser to the end user. The ExplorerBrowser control found inside the Microsoft Windows API CodePack contains much of the functionality I need... e.g. thumbnails of different sizes, sorting, browsing, etc...
The catch is that the files are not coming from the disk, but are available over a custom network transfer protocol.
I was originally thinking that I could simply extend the ShellObjectContainer class and ShellObject classes to provide the features I require, by essentially building an Adapter. However I've run into difficulties because these classes use internal constructors.
Overall it's looking like this API is rather hostile to extension, is there anyway to extend these components to do what I need, or am I better rebuilding much of ExplorerBrowsers functionality by creating a custom WPF component, perhaps by extending ListBox?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，这当然不是为了可扩展的。除非您创建自己的 shell 命名空间扩展，否则很难看出您如何能够到达任何地方。这样就可以在 shell 窗口中查看它。在托管代码中这样做是相当残酷的，从 IUnknown 派生的 shell 的 COM 接口非常难以使用。这就是 API 代码包中的包装类在托管程序中获取浏览器窗口的作用。
创建 shell 命名空间扩展是更好的解决方案，您的自定义文件也将在常规资源管理器窗口中可见。但是，请用 C++ 编写此类代码，因为这样可以更轻松地运行 COM 代码，并且可以避免在任何使用“文件 + 打开”对话框的程序中注入 CLR。尽管现在 .NET 4.0 在技术上支持这一点
Yes, this certainly wasn't made to be extensible. Hard to see how you could get anywhere at all unless you create your own shell namespace extension. So that it is viewable in a shell window. Doing so is quite brutal in managed code, the shell's COM interfaces derived from IUnknown are very hard to use. Which is what the wrapper classes in the API code pack is doing to get a browser window in a managed program.
Creating the shell namespace extension is the greater solution, your custom files would be visible in a regular Explorer window as well. But write that kind of code in C++, both because it is so much easier to get the COM code going and to avoid injecting the CLR in any program that uses a File + Open dialog box. Although that is now technically supported by .NET 4.0