ShellIconOverlayIdentifiers 和 windows10 [英] ShellIconOverlayIdentifiers and windows10

问题描述

图标覆盖对我来说是一个烦人的问题.在 windows10 上，您似乎可以设置 11 个(或者是 10 个?)覆盖图标，其他图标将被忽略.这是一个非常低的数字，即使是一项服务也很容易使用.

Icon overlays are becoming an annoying problem for me. On windows10 it seems like you can have 11 (or is it 10?) overlay icons set, others are ignored. This is very low number that is easily used even by one service.

因此，windows 只采用按字母顺序排列的前 N ​​个设置，这开始了以下小趋势.

So windows just takes first N settings as by alphabetical order which started the following petty trend.

这是我的注册表:

如您所见，公司开始添加空间以排在订单的前面.在最近的更新 Dropbox 中已经添加了第三个空间！

As you can see, companies started adding spaces to get to the front of the order. In recent update dropbox added third space already!

问题:1) 有没有办法使用字母顺序以外的其他方式告诉 windows 使用哪些 N 设置(尽可能多的 windows 支持)?

Question: 1) Is there a way to use something else than alphabetical order to tell windows which N settings (as much as windows supports) to use?

2) 有没有办法增加有效标识符的数量?

2) Is there a way to increase the number of identifiers in effect?

推荐答案

不，没有办法增加 15 个图标限制，这是 Windows 多年来的限制.

No, there is no way to increase the 15 Icon Limit, this is a Limitation in Windows for years.

每个图像列表都包含一个用作叠加层的索引列表.一个覆盖是在另一个图像上透明绘制的图像.当前在图像列表中的任何图像都可以用作叠加层.你每个图像列表最多可以指定四个叠加层.这个限制已经在 4.71 版本中扩展到 15 个.

Every image list includes a list of indexes to use as overlays. An overlay is an image that is drawn transparently over another image. Any image currently in the image list can be used as an overlay. You can specify up to four overlays per image list. This limit has been expanded to 15 in version 4.71.

所以限制在 Comctl32.dll 中，我们可以不修.覆盖处理程序按 ASCII 代码的顺序加载.所以增加更多的步数会更早加载它们.我删除了 Dropbox 5-10 个图标 + TSV4 + 5，因为我不使用锁定.我也不使用 Onedrive，所以我最多有 15 个叠加层.

So the limit is in Comctl32.dll and we can't fix it. The overlay handler are loaded by the order of the ASCII code. So adding more paces loads them earlier. I delete the Dropbox 5- 10 icons + TSV4 + 5 because I don't use locking. I also don't use Onedrive, so I have a max of 15 overlays.

微软似乎注意到了更多图标的需求，Raymond Chen 写了一些关于这个问题的细节:

It looks like Microsoft noticed the demand of more icons and Raymond Chen wrote some details about the issue:

16 位限制是从 16 位版本的通用控件(在 Windows 95 中仍需要支持).的当然，如今，没有人关心 16 位版本的通用控制，那么为什么不开始使用高位呢?

The 16-bit limit was carried over from the 16-bit version of the common controls (which still needed to be supported in Windows 95). Of course, nowadays, nobody cares about the 16-bit version of the common controls, so why not start using the upper bits?

有个不满意的解释:内部管理的代码fStyle 在某些地方仍然使用 WORD，所以所有的代码管理 fStyle 将不得不被修改.这发生在多个跨 Windows 的模块，因此必须进行同步更改跨多个组件.这是二进制文件的重大更改级别，因为接口不再兼容. 中断更改在程序上难以协调:受影响的代码壳团队可能看不到，因为他们坐在一个尚未 RI 到树干的远处叶分支.有可能将 fStyle 从 WORD 扩展为 DWORD 具有深远的意义某些组件的后果.

There’s an unsatisfying explanation: The code internally that manages the fStyle still uses a WORD in some places, so all the code that manages the fStyle would have to be revised. This occurs in multiple modules across Windows, so a synchronized change would have to be made across multiple components. This is a breaking change at the binary level because the interfaces are no longer compatible. Breaking changes are procedurally difficult to coordinate: The affected code may not be visible to the shell team because they are sitting in a far-away leaf branch that has not yet RI’d to the trunk. It might be that expanding fStyle from a WORD to a DWORD has far-reaching consequences for some component.

因此这是一个历史限制，更改它可能会破坏 Windows shell 之外的其他组件.

So it is an historic limit and changing it can break other components beside the Windows shell.

这篇关于ShellIconOverlayIdentifiers 和 windows10的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！