Konst_Oneнесанкционированное управление сторонней программой противозаконно

Гы :) такой статьи в УК пока нету :)

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

Всё взаимодействие на уровне API - осуществляется через функцию

BOOL Shell_NotifyIcon(
DWORD dwMessage,
PNOTIFYICONDATA lpdata
);

где dwMessage - может быть:

NIM_ADD
NIM_DELETE
NIM_MODIFY
NIM_SETFOCUS

В данной ситуации нужно воспользоваться сообщением NIM_DELETE, которое необходимо послать от лица программы, значок которой нужно убрать из трея. Но тут - болт, который сидит во втором параметре функции - Shell_NotifyIcon.

Второй параметр - указатель на структуру NOTIFYICONDATA в поле uID которой содержится идентификатор "сеанса", открытого к трею - некий числовой идентификатор, который нужно знать, для того чтобы обращаться к добавленной иконке. Если хэндл окна любого запущенного приложения можно узнать и продублировать его для использования в своём процессе - пусть и с ограничениями и даже вообще без предположения о том связан сеанс трея именно с этим окном, или с другим (ничего плохого не случится если окно не инициирует работу с треем)... то вот этот самый идентификатор сеанса откуда ты узнаешь? будешь перебирать все окна процесса и для каждого хэндла окна перебирать все возможные идентификаторы? а их в DWORD - влезит 4 миллиарда с копейками... так что вся эта идея - ерунда. И - интересно, что за такая перспективная программка?

BelowZero,

Да ну нет же шь :)

Когда я отправляю NIM_ADD = я указываю этот код... системе, трею и прочим - абсолютно пофигу, что я туда передам... просто если приложение создаёт несколько иконок - оно как то должно различать их для того, чтобы допустим поменять состояние именно той иконки, которая нужна, а не другой...

Посмотри во вложении - небольшой пример...

Там я определяю две константы

Const TrayCellId_1 As Long = 1000
Const TrayCellId_2 As Long = 2000

для первой иконки в трее, и для второй...

То что сделали для XP - это вероятнее всего частный случай и не универсальный, т.к. думаю что приложения которые добавляют в трей только одну иконку - передают в качестве ID какое то значение 0 или 1 - которое возможно и повторяется (с некоторой долей вероятности)... я вот например передаю туда 1000 и 2000... кто нибудь другой передаст 3000 и 4000... и т.д. Я вот об этом пытаюсь сказать... единственный способ - это наверное сабклассинг самого трей окна... но для этого нужно в деталях знать что и где там происходит...

BelowZero,

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

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

BelowZero,

Мы на этой ступени и находились... если бы вы внимательно читали мой пост (3-й сверху), а не гнались за "неведомым счастьем" - вы бы на это обратили внимание :)

Так же действительно рекомендую прислушаться к словам "Игорь Горбонос"

Хотя пока мы тут спорим - в моём больном мозгу проскочила одна идея... попробую её на практике и сообщу о результатах позднее...