我为Windows构建了一个虚拟文件系统(不是命名空间扩展),它充当我们的文件管理服务器的前端,包括文件和文件夹。为了能够在Windows资源管理器中显示DMS对象的一些元数据作为附加可选列,我通过实现COM属性处理程序成功地向Windows属性系统提供了属性。 Wheras普通属性处理程序专注于他们认为负责的特定文件类型,我的属性处理程序将属性添加到所有文件,而不管其类型如何。因为属性处理程序只能在文件类型级别注册,所以我在
下注册了大约30种类型的处理程序
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
但是,我没有设法为文件夹对象注册属性处理程序。由于我们的文件系统中的所有对象都是虚拟的,因此我通过实现IPropertyStore
而不是IInitializeWithFile
来构建属性存储(IInitializeWithStream
)。从我们的DMS请求属性,IInitializeWithFile
的路径作为密钥,不从对象内容中读取。这个概念也适用于文件夹。
为了调用文件夹,我尝试通过在Folder
,Directory
,AllFileSystemObjects
和*
等不同的众所周知的标识符下注册而不是文件扩展名来关联处理程序没有成功。
我也没有在MSDN文档中找到任何关于这方面的内容。
有没有办法在文件夹上注册Windows属性处理程序?或者是否有其他方法可以在Windows资源管理器中向文件夹添加自定义列?
答案 0 :(得分:1)
我不确定是否可以这样做。
属性处理程序显然不是正确的方法,它们是系统范围的,每个文件扩展名只能有一个。它们只能由“拥有”文件扩展名的软件实现,并且可以解析文件以提取属性。
旧的列处理程序将是你最好的选择(恕我直言),但他们已经正式死亡,你已经说过你不能使用它们。
您是否考虑过创建命名空间扩展?作为某个根源项目(桌面或我的电脑),我的文档在2000 / XP中的工作方式,或者更像是OneDrive的工作方式?
我不确定desktop.ini文件是否有效in the root of a drive,但可能值得研究。然后,您将发现自己位于[.ShellClassInfo]
class Array
def push_with_default(item, index, &block)
new_arr = Array.new([self.size + 1, index].max, &block)
self[index] = item
self.map!.with_index { |n, i| n.nil? ? new_arr[i] : n }
end
end
>> array = [1,2,5,9]
[
[0] 1,
[1] 2,
[2] 5,
[3] 9
]
>> array.push_with_default(2, 10) { |i| "column_#{i}" }
[
[ 0] 1,
[ 1] 2,
[ 2] 5,
[ 3] 9,
[ 4] "column_4",
[ 5] "column_5",
[ 6] "column_6",
[ 7] "column_7",
[ 8] "column_8",
[ 9] "column_9",
[10] 2
]
以及其CLSID,CLSID2和UICLSID成员。一般的想法是在“真正的”IShellFolder之上充当IShellFolder代理,这样你就可以创建一个poorly documented。我认为你可以覆盖一些(未记录的?)属性键来更改文件夹的默认列和工具提示。
还有一个名为multiplex property store的东西可以让你玩嵌套的PIDL,但文档再次没用,所以我不确定这是否值得研究。
第三种选择是伪装成delegated folder。我不知道这是否会让你更接近你的目标,你仍然需要实现一些NSE位来达到你可以在底层的IShellFolder上层层叠叠的程度。此功能相当新,仅记录在Windows 10上。
Explorer / IShellBrowser如何连接到IShellFolder / IShellView的内部工作原理是Windows中记录最少的部分之一。有数百个未记录的接口。资源管理器cloud storage provider让其他第三方实现冷落。
我的感觉是,在驱动器号上没有干净的解决方案可以实现这一点,但你可能会很幸运,如果Raymond Chen下台,他可能会为你提供一些技巧......