标签: shell-extensions

我创建了一个小脚本来更改文件名(用_等替换空格).我用参数控制这个脚本.

现在我想将它包含在我的explorer-shell-extention中,所以我尝试添加以下注册表项:

HKEY_CLASSES_ROOT\*\shell\edit filname method a\command
HKEY_CLASSES_ROOT\*\shell\edit filname method b\command
HKEY_CLASSES_ROOT\*\shell\edit filname method c\command

等等.

它工作正常,但我想将所有这些方法打包成一个子菜单.有点像"开放式"选项.那可能吗？

如何编写shell扩展来显示像Gmail Drive一样的虚拟驱动器中的在线文件？

该建议曾经是"不要在托管代码中编写进程内shell扩展".

但是,对于.NET Framework 4和In-Process并排,应该解决不在托管代码中编写shell扩展的主要原因.

话虽如此,我有三个问题.

1. 现在可以在托管代码中编写shell扩展吗？
2. 在托管代码中编写shell扩展可能存在哪些问题？
3. 在非托管代码中编写shell扩展可能有什么原因？

您好我正在运行Visual Studio 2010并且在32位计算机上具有完全在32位上运行的上下文菜单shell扩展,因此存在所有方法.这是一个ATL项目.32位没有错误甚至警告.

这是问题所在.当我进入visual studio下的配置管理器并将活动解决方案平台从Win32切换到x64并尝试编译时我得到错误"错误C2259:'ATL :: CCOMObject:无法实例化抽象类".

由于这个完全相同的项目在32位编译和运行,为什么它会让我误解为x64？

任何想法或正确方向的一点将不胜感激.
主要方法是必需的并且实施如下:

STDMETHODIMP Initialize(LPCITEMIDLIST, LPDATAOBJECT, HKEY);
STDMETHODIMP GetCommandString(UINT, UINT, UINT*, LPSTR, UINT);
STDMETHODIMP InvokeCommand(LPCMINVOKECOMMANDINFO);
STDMETHODIMP QueryContextMenu(HMENU, UINT, UINT, UINT, UINT);

保存代码空间创建Atl项目.一旦创建了初始项,添加一个新类"TestingContextMenu"其余的代码将引用它.

stdafk.h

#include "resource.h"
#include <atlbase.h>
#include <atlcom.h>
#include <atlctl.h>
#include <shlobj.h>
#include <comdef.h>

#include <string>
#include <list>
typedef std::list< std::basic_string<TCHAR> > string_list;

TestingContextMenu.h仅包含已添加/更改的部分

#include "stdafx.h"
using namespace std;
class ATL_NO_VTABLE CTestingContextMenu:
        public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CTestingContextMenu, &CLSID_TestingContextMenu>,
    public IShellExtInit,
    public IContextMenu
    {
        // Comment out or remove IDispatch
BEGIN_COM_MAP(CMainMagnimbusContextMenu)
    //COM_INTERFACE_ENTRY(ITestingContextMenu)
    //COM_INTERFACE_ENTRY(IDispatch)
    COM_INTERFACE_ENTRY(IShellExtInit) …

CodeProject有一个很棒的Windows shell扩展教程.

编译,运行Regasm.exe CSShellExtContextMenuHandler.dll /codebase和shell扩展可用,它工作得很好.

但要求用户运行Regasm不是用户友好的,所以我在下面编写了小的WiX脚本.(只是复制了输出heat,加上我想要使用的依赖DLL).

问题:当我安装生成的MSI时,不会出现shell扩展(在Windows资源管理器中,右键单击文件不显示我的项目,尽管它正在使用Regasm)

<?xml version='1.0' encoding='windows-1252'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'>

  <Product Name='HelloWorld Shell Extension' Id='2afd44ab-16d7-40f4-8741-69ad546cb7cf' UpgradeCode='c5139d19-21ba-43c6-a17d-68760331f332'
    Language='1033' Codepage='1252' Version='0.4.4' Manufacturer='Me'>

    <Package Id='*' Keywords='Installer' Description="HelloWorld Shell Extension Setup" Manufacturer='Me'
      InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' />

    <Media Id='1' Cabinet='HelloWorldShellExtension.cab' EmbedCab='yes' DiskPrompt='HelloWorld CAB' />
    <Property Id='DiskPrompt' Value="HelloWorldShellExtension Bundle CAB Installation" />

    <Directory Id='TARGETDIR' Name='SourceDir'>
      <Directory Id='ProgramFilesFolder' Name='PFiles'>
          <Directory Id='INSTALLDIR' Name='HelloWorldShellExtension'>
            <Component Id="cmpB0970E4FB9610FC20E1C6B6B2D45C606" Guid="7044db96-17d3-4d4f-93b0-135b89b042c8">
                <Class Id="{CE43A2AB-B457-49BF-C83F-4306208D438B}" Context="InprocServer32" Description="CSShellExtContextMenuHandler.FileContextMenuExt" ThreadingModel="both" ForeignServer="mscoree.dll">
                    <ProgId Id="CSShellExtContextMenuHandler.FileContextMenuExt" …

我试图用C++中的自定义面板扩展whindows explorer(NOT IE),它应该如下所示:

这是我发现的类似问题(在C#中): 类似的问题

问题是C#,已经得到了答案.

但是我自己发现答案对我来说有点太简短了,这就是我得到的:

1. 我应该实现一个BHO对象
2. BHO对象应该实现IObjectWithSite和IDockingWindow
3. 在SetSite方法中,调用QueryInterface获取服务提供者的指针,然后调用QueryService获取Docking窗口框架的指针,最后调用AddToolBar添加我的自定义窗口.而这里是我迷路的地方

我的问题是:

1. 我应该在什么时候创建自定义窗口？在初始化对象期间？
2. 我想我应该得到一个父窗口的句柄(在我的情况下,我认为它应该是Windows资源管理器的句柄),然后才能创建我自己的窗口,这将是它的一个孩子,我在哪里可以得到这个句柄？与对接窗框的指针？
3. 我该如何注册我的dll？我读了一些预览处理程序的示例代码,我们必须在系统调用之前正确注册dll吗？

我试图重现类似的问题几天所说的,但现在没有运气.

我是BHO的新手和所有这些东西,请帮助我解决这个问题,谢谢.

前提:

我有一个旧的32位COM shell扩展(用C++编写).经过多年与更新的64位系统的不兼容,我们现在正在更新它以在64位Windows环境中工作.

诀窍:

32位COM DLL包含对第三方库的依赖性,对于这些库,没有可用的64位版本.因此,我们不能简单地"重新编译64位".鉴于此限制,我们决定最简单的方法是创建一个"瘦"的64位DLL; 本质上是一个空DLL,只定义所需的接口,并将所有调用重定向到底层的32位COM DLL.

我相信通过使用COM代理,可以在64位COM DLL和32位COM DLL之间进行通信.不幸的是,这似乎是一个非常具体/小众的主题,我一直无法找到很多关于如何从64位COM DLL调用32位COM API的资源.

问题:

• 这个'瘦COM包装器'是一种合理的方法,用于启用32位COM DLL的64位功能吗？
• 是否有任何理由这种方法不适用于Windows Shell Extensions？
• 64位接口定义是否会使用与32位接口相同的GUID？
• 这是过去记录的策略吗？
• 在64位COM DLL中调用32位COM API有什么好的资源吗？

澄清:

这个问题有许多方面使它独特,使其与" 在Windows 7 64位中使用32位外壳扩展 "这一问题区分开来.

我不是在询问是否可以在64位资源管理器进程中加载​​32位shell扩展,正如引用的问题所做的那样.相反,我问是否有可能创建DLL的精简64位实现,它充当64位资源管理器进程和32位实现之间的桥梁.

要清楚,这是不可能的.

但也许这是？

当前，我的属性处理程序提供的属性可以显示在Windows资源管理器的type列中String。我的目标是通过（显示）类型Icon的属性扩展处​​理程序，该属性可以作为列添加到Windows资源管理器的详细信息视图中。在此列中，应该为每个文件项目显示一个图标，例如，该图标可以代表几种可能状态中文件的特定状态。

但是，我没有在Windows属性系统的基础上正确地组合创建具有这些特征的属性的必要部分。

我的方法的第一步是在.propdesc文件中为属性指定XML ，然后执行通常的PSRegisterPropertySchema注册过程。这将始终成功运行，并且该属性在Windows属性系统中列出。

<propertyDescription name="myprop.icon" formatID="{c5f47221-1053-4a75-aadc-0bfbac1c3e9c}" propID="444">
    <typeInfo type="???" isInnate="true" isViewable="true"/>
    <labelInfo label="MyProp-Icon"/>
    <displayInfo defaultColumnWidth="25" alignment="Center">
        <drawControl control="IconList"/>
    </displayInfo>
</propertyDescription>

的存在<drawControl>（drawControl）与control类型的属性"IconList"的内部<displayInfo>标签让我觉得我的想法可能是可行的。

但是如何type在<typeInfo>标签（typeInfo）中设置相应的内容呢？根据概念的不同，control="IconList"它可以是一个整数，作为像图像列表一样的索引。或者它是一个"Buffer"，"Blob"或者"Stream"表示图像本身？

最后，在GetValue()属性处理程序外壳扩展的方法PROPVARIANT中，必须根据.propdesc文件的属性描述进行初始化：

HRESULT PropertyHandler::GetValue (REFPROPERTYKEY key, PROPVARIANT *pPropVar)
{
    HRESULT hr = ERROR_NOT_FOUND;

    if (key.pid == 444)
    { …

我最近观察到，我的文件夹预览处理程序未在 Windows 10 版本 1709 上实例化。这令人惊讶，因为该处理程序在从 Windows 7 到 Windows 10 版本 1607 运行的系统上都能完美运行。

预览处理程序以标准化方式在ProgID 下注册Directory：

HKEY_CLASSES_ROOT
    Directory
        shellex
            {8895b1c6-b41f-4c1c-a562-0d564250836f}
                (Default) = [REG_SZ] {1F176730-9812-47D8-8163-35D7C1CA0FBF}

可以通过监视 Windows 资源管理器的注册表访问来跟踪工作系统和非工作系统之间的差异。当在 1607 系统上请求预览文件夹时，进程监视器会生成预期的输出：

另一方面，在 1709 系统上，该HKEY_CLASSES_ROOT\Directory键下根本没有注册表访问权限。这就是为什么我怀疑不同的行为（不幸的是）与我的处理程序代码没有任何关系，并且对文件夹的预览处理程序支持可能已在最近的 Windows 版本中删除。

我还使用ProgID Folder进行了测试，而不是Directory没有成功，并验证了我的预览处理程序通常会实例化，至少在文件上，通过在AllFileSystemObjects.

有人有在最新 Windows 版本上运行文件夹预览处理程序的经验吗？

据我了解，目前有两种方法可以使用资源管理器从 Shell 命名空间扩展复制虚拟文件，以便向用户显示复制 GUI：

1. 通过IDataObject接口：

   读取文件是通过至少IDataObject::GetData支持CFSTR_FILEDESCRIPTORW,CFSTR_FILECONTENTS和剪贴板格式来完成的。CFSTR_SHELLIDLIST请求应创建一个用于访问数据的对象CFSTR_FILECONTENTS。当需要时，通过设置标志来启用 UI 。IDataObject::GetDataIStreamFD_PROGRESSUICFSTR_FILEDESCRIPTORW

   

2. 通过ITransferSource接口：

   读取文件是通过ITransferSource::OpenItem请求IShellItemResources. 然后IShellItemResources应将{4F74D1CF-680C-4EA3-8020-4BDA6792DA3C}资源报告为受支持（GUID 指示该项目有一个 IStream）。最后，IStream通过父级请求ShellFolder::BindToObject访问数据。UI 由资源管理器本身处理，它始终显示。

   

我的问题是：这两种机制单独工作得很好（正如您从屏幕截图中看到的）。但是一旦我启用了IDataObjectfromIShellFolder::GetUIObjectOf和ITransferSourcefrom IShellFolder::CreateViewObject- 总是使用 via 方法IDataObject，导致旧的副本 GUI（如第一个屏幕截图所示）。我从跟踪日志中看到ITransferSource多次请求，但没有执行任何操作，它只是立即释放并销毁。

那么，当从 Shell 命名空间扩展进行复制时，如何强制资源管理器显示精美的复制 GUI？

可以在这里找到最小的可重现示例：https://github.com/BilyakA/SO_73938149

在研究最小可重复示例时，我设法使其在启用IDataObject和ITranfserSource接口的情况下按预期工作。事情发生在之后：

1. 未注册的 x64 构建 SNE 示例 ( regsvr32 /u …