Запуск зарегистрированного приложения-помощника MIME

Question

Раньше я мог запускать локально установленное вспомогательное приложение, регистрируя данный mime-тип в реестре Windows. Это позволило мне позволить пользователям один раз щелкнуть ссылку на текущую установку нашего внутреннего браузера. Это отлично работало в Internet Explorer 5 (в большинстве случаев) и Firefox, но теперь не работает в Internet Explorer 7.

Имя файла, переданное моей команде shell / open /, не является полным физическим путем к загруженному установочному пакету. Параметр пути, который мне передает IE, равен

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
  EIPortal_DEV_2_0_5_4[1].expd"

Это, к сожалению, не разрешается в физический файл при вызове FileExists() или при попытке создать объект TFileStream.

В физическом пути отсутствует подкаталог скрытого кэширования Internet Explorer для временных файлов Интернета "Content.IE5\ALBKHO3Q", абсолютный путь которого будет выражаться как

"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\ 
  Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"

Да, подкаталоги генерируются случайным образом IE, и это не должно вызывать беспокойства, пока IE передает полный путь к моему вспомогательному приложению, чего, к сожалению, он не делает.

Установка приложения mime helper не является проблемой. Он устанавливается / обновляется глобальным сценарием входа для всех 10 000 пользователей по всему миру. Помощник mime вызывается только тогда, когда пользователь нажимает на внутреннюю веб-страницу со ссылкой на установку нашего приложения браузера для настольных ПК. Эта установка возвращается с типом пантомимы "application/x-expeditors". Регистрация типа mime ".expd" / "application/x-expeditors" выглядит следующим образом.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd] 
@="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
@=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
@="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"

Я рассмотрел возможность перечисления всех записей кэша пользователя IE, но меня беспокоит, сколько времени может потребоваться, чтобы изучить их все, или что я могу в конечном итоге найти более старую запись кэша до текущей записи, которую я ищу. Однако суффикс имени файла в скобках "[n]" может быть уникальным ключом.

Я пробовал метод wininet GetUrlCacheEntryInfo, но для этого требуется URL, а не виртуальный путь, передаваемый IE.

Я надеюсь, что есть функция Shell, которая при задании виртуального пути возвращает физический путь.

Answer 1

Некоторое продолжение, чтобы закрыть этот вопрос.

Оказалось, что реальная проблема заключалась в том, как я создавал дескриптор файла, используя TFileStream. Я изменил, чтобы открыть с fmOpenRead или fmShareDenyWrite , что решило проблему блокировки файла.

srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);

Answer 2

Похоже, iexplore передает пространство имен оболочки "имя" файла, а не имя файловой системы.

Я не думаю, что есть документированный способ передачи идентификатора элемента оболочки в командной строке - проводник делает это сам с собой, но существуют соображения маршалинга, поскольку идентификаторы элементов оболочки (указатели на) являются структурами двоичных данных, которые являются действительными в одном процессе.

Я мог бы попытаться сделать следующее: 1. Вызвать SHGetDesktopFolder, который вернет корневой объект IShellFolder пространства имен оболочки. 2. Вызвать IShellFolder :: ParseDisplayName, чтобы превратить заданное имя в список идентификаторов элементов оболочки. 3. Попробуйте IShellFolder :: GetDisplayNameOF с флагом SHGDN_FORPARSING - который, честно говоря, кажется, что мы только что прошли полный круг и вернулись к тому, с чего начали. Потому что я думаю, что именно этот API в конечном итоге отвечает за возврат «неправильного» относительного пути файловой системы.

Answer 3

Я не уверен в этом, но, возможно, это может привести вас в правильном направлении: попробуйте использовать функции кэширования URL из DLL-библиотеки wininet: FindFirstUrlCacheEntry , FindNextUrlCacheEntry , FindCloseUrlCache для перечисления, и когда вы находите запись, локальное имя файла которой соответствует заданному пути, возможно, вы можете использовать RetrieveUrlCacheEntryFile для извлечения файла.

Answer 4

Я использую аналогичную систему с браузером X-Appl для отображения веб-приложений WAML, и она отлично работает. Может быть, вам стоит взглянуть на то, как им это удалось.

Answer 5

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

Не лучше ли установить этот помощник в данные приложения?