NOTIFYICONDATA - проблема с GUID - PullRequest
Новая
       13

NOTIFYICONDATA - проблема с GUID

5 голосов
/ 15 сентября 2011

В соответствии с описанием для элемента guidItem структуры NOTIFYICONDATA в http://msdn.microsoft.com/en-us/library/bb773352(v=vs.85).aspx программам, использующим системный трей Windows, необходимо идентифицировать их значок с действительным GUID в Windows 7. Я сделал это, но я сталкиваюсь с проблемой. Если мое приложение выполняется в каталоге A, а затем пользователь в какой-то момент решает переместить его и запустить его в каталоге B, когда программа выполняет вызов Shell_NotifyIcon, она завершается неудачно (возвращает 0) с GetLastError, установленным в 1460 (ERROR_TIMEOUT).

Если вы прочтете в самом низу этой статьи MSDN пункт 2 для поиска и устранения неисправностей, в основном описывается, что программы, идентифицирующие значок на панели задач с GUID, не могут изменить пути или это произойдет. В нем также есть эта интересная небольшая реклама:

Если необходимо изменить путь, приложение должно удалить любой GUID информация, которая была добавлена ​​при регистрации существующего значка.

Кто-нибудь знает вызов Win32 API или способ сделать это? Предположительно, это будет функция, принимающая GUID, который я хочу удалить, и вызов ее удалит все настройки для любого exe-файла, который Windows определил как использующий этот GUID. Если это так, я могу настроить свою программу на попытку вызова Shell_NotifyIcon, а затем, если она не удастся, я вызову функцию, чтобы очистить все и попытаться снова.

Единственный другой вариант, который я могу придумать, - разрешить программе, которая может запускаться в нескольких местах (не в одно и то же время), использовать один и тот же GUID для значка на панели задач, - просто изменить настройки в реестре в соответствии с этой статьей: http://deployment.xtremeconsulting.com/2011/07/08/windows-7-notification-area-automation-falling-back-down-the-binary-registry-rabbit-hole/ Я хотел бы избежать этого подхода, если это возможно, по понятным причинам.

Любая помощь по этому вопросу будет принята с благодарностью.

1 Ответ

3 голосов
/ 13 января 2012

Вот полный список известных мне возможностей:

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

Давайте рассмотрим эту последнюю идею, в частности.Windows хочет уникальный GUID для каждого пути.Нам просто нужен GUID, который не меняется, пока путь фиксирован.Это на самом деле тривиально, чтобы достичь.Вот схема:

  • сгенерируйте случайный GUID, используя такой сервис, как сделайте guid
  • получите путь к исполняемому файлу
  • хешируйте свой путь с помощьюхеш-функция, которая выводит не менее 128 бит, например, MD5 или SHA-1
  • XOR ваш GUID с помощью хэша пути, усеченного до 128 бит
  • , используйте результат в качестве иконки в трее GUID

Это связано с ошибкой: путь к приложению не обязательно уникален.Но это не должно быть серьезной проблемой, потому что, во-первых, в большинстве случаев оно уникально, а во-вторых, худшее, что может произойти, если запустить его по альтернативному пути, это то, что пользователю придется переместить значок в трее раз .

...