Всем привет.

Задача — написать расширение оболочки для .pdf файлов (контекстное меню).
Методом тыка нашел нужную ветку реестра, куда надо зарегистрировать свою сборку:
HKEY_CLASSES_ROOT\AcroExch.Document.7\shellex\ContextMenuHandlers\PdfSplitter

При добавлении в HKEY_CLASSES_ROOT\.pdf\... и HKEY_CLASSES_ROOT\AcroExch.Document\... не работает.

Вопрос — почему именно в эту ветку? Какие правила использует оболочка для поиска расширений?

Здравствуйте, Аноним, Вы писали:

А>Всем привет.

А>Задача — написать расширение оболочки для .pdf файлов (контекстное меню).
А>Методом тыка нашел нужную ветку реестра, куда надо зарегистрировать свою сборку:
А>HKEY_CLASSES_ROOT\AcroExch.Document.7\shellex\ContextMenuHandlers\PdfSplitter

А>При добавлении в HKEY_CLASSES_ROOT\.pdf\... и HKEY_CLASSES_ROOT\AcroExch.Document\... не работает.

А>Вопрос — почему именно в эту ветку? Какие правила использует оболочка для поиска расширений?

читать здесь

Автор(ы): Michael Dunn
Дата: 17.04.2001

DB>читать здесь

Автор(ы): Michael Dunn
Дата: 17.04.2001

Спасибо за ссылку, но эту статью я уже прочитал, собственно по ней расширение и писал.
Однако там не объясняется почему автор выбрал для .txt файлов ветку HKCR\txtfile, очевидно потому что в default значении для HKCR\.txt прописано это имя (txtfile).

Но с .pdf такой трюк не проходит. Если вы посмотрите на default значение HKCR\.pdf, то оно равняется AcroExch.Document (при установленных продуктах Adobe). Ищем эту ветку, регистрируем расширение и привет, ничего не происходит. Однако там есть подсказка в виде подветки CurVer со значением AcroExch.Document.7. Вот туда то (в HKCR\AcroExch.Document.7) и надо прописывать свое расширение. Мне не ясно почему так. Какой логикой руководствуется оболочка? Как гарантировать, что при любой конфигурации расширение будет работать?

Как вариант я уже думал регистрировать под HKCR\*. Но это крайний случай, не хочется чтобы при любом вызове контекстного меню шелла к процессу прилипала моя сборка с CLR вдовесок.

Здравствуйте, sada12, Вы писали:

S>Как вариант я уже думал регистрировать под HKCR\*. Но это крайний случай, не хочется чтобы при любом вызове контекстного меню шелла к процессу прилипала моя сборка с CLR вдовесок.

расширение оболочки с менеджд кодом это вообще моветон. Никто не гарантирует что в процессе оболочки не загружен CLR, более того, он там может оказаться другой версии. Всё, приплыли.

Согласен, проблема есть. Однако не хочется переписывать весь код под MFC, etc. из-за всего одной функции.
Будем думать дальше. Можно, например, расширение написать на родном С++ и на обработчик меню повесить запуск основного управляемого приложения. Путь к файлу в аргументе.

p.s. Да, основной вопрос остается.

Здравствуйте, <Аноним>, Вы писали:

А>При добавлении в HKEY_CLASSES_ROOT\.pdf\... и HKEY_CLASSES_ROOT\AcroExch.Document\... не работает.
А>Вопрос — почему именно в эту ветку? Какие правила использует оболочка для поиска расширений?

Здесь смотрел?
MSDN: Extending Shortcut Menus

Здравствуйте, Буравчик, Вы писали:

А>>При добавлении в HKEY_CLASSES_ROOT\.pdf\... и HKEY_CLASSES_ROOT\AcroExch.Document\... не работает.
А>>Вопрос — почему именно в эту ветку? Какие правила использует оболочка для поиска расширений?

Б>Здесь смотрел?
Б>MSDN: Extending Shortcut Menus

Спасибо за ссылку. Почитав статью, нашел рядом еще пару статей, в которых и обнаружилась разгадка. Благодарствую.

Если кому интересно, алгоритм такой:
1) по расширению в соответствующем ключе (HKCR\.pdf) в значении (Default) находится ProgID — программный идентификатор (аналог CLSID), в моем случае это "AcroExch.Document";
2) в ветке идентификатора (HKCR\AcroExch.Document) находим значение CurVer, которое имеет специальный смысл, а именно — указывает на текущую версию идентификатора, в которой оболочка и ищет расширения, в моем случае — AcroExch.Document.7;
3) открывается ветка текущей версии (HKCR\AcroExch.Document.7), расширения надо регистрировать в ней

Ссылки на статьи:
простой пример
Programmatic Identifiers

Вопрос закрыт.