Re[8]: Проверить/отловить доступность TaskBar - как?
От: okman Беларусь https://searchinform.ru/
Дата: 15.12.12 11:25
Оценка:
Здравствуйте, Carc, Вы писали:

C>Все просто: к моменту старта софтины тескбар уже создан, и соответственно рассылать сообщение "TaskBarCreated" он уже больше не будет. Т.к. уже создан. А мои две софтины, стоящие в автостарте судя по всему попадают где-то в промежуток. Т.е. они попросту не успевают получить TaskBarCreated, именно потому что они подписываются на его получение (пущают свою WndProc несколько позже). Соответственно дожидаться больше нечего. Таскбар есть, сообщение больше рассылаться не будет. Полагаться на поиски через FindWindow в те еще прятки играть с Microsoft. Завтра они что-нить переименуют в классах окна, и код нерабочим становится. Остается только полагаться на Shell_NotifyIcon + NIM_ADD.


А нельзя ли поступить проще ?
Ведь задача состоит лишь в том, чтобы:

1. Гарантированно запостить свою иконку в трей при автозагрузке.
2. Сделать это заново при возможном перезапуске оболочки.

Пункт 1 успешно решается вызовом Shell_NotifyIcon в цикле с некоторой задержкой,
до тех пор, пока функция не вернет TRUE. Например, по WM_TIMER.

Пункт 2 решается подпиской на сообщение TaskbarCreated и снова запуском Shell_NotifyIcon в цикле.

Уверен, что так будет работать.

P.S.
Кстати, в Windows 7 юзать трей уже не модно — там есть ITaskbarList3 и т.п.
И там аналогичные проблемы с отловом запуска/перезапуска таскбара — "TaskbarButtonCreated".
Re[9]: Проверить/отловить доступность TaskBar - как?
От: Carc Россия https://vk.com/gosha_mazov
Дата: 15.12.12 11:58
Оценка:
Здравствуйте, okman, Вы писали:

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


C>>Все просто: к моменту старта софтины тескбар уже создан, и соответственно рассылать сообщение "TaskBarCreated" он уже больше не будет. Т.к. уже создан. А мои две софтины, стоящие в автостарте судя по всему попадают где-то в промежуток. Т.е. они попросту не успевают получить TaskBarCreated, именно потому что они подписываются на его получение (пущают свою WndProc несколько позже). Соответственно дожидаться больше нечего. Таскбар есть, сообщение больше рассылаться не будет. Полагаться на поиски через FindWindow в те еще прятки играть с Microsoft. Завтра они что-нить переименуют в классах окна, и код нерабочим становится. Остается только полагаться на Shell_NotifyIcon + NIM_ADD.


O>А нельзя ли поступить проще ?

O>Ведь задача состоит лишь в том, чтобы:

O>1. Гарантированно запостить свою иконку в трей при автозагрузке.

Именно об этом и речь.
O>2. Сделать это заново при возможном перезапуске оболочки.
Это не обсуждалось. Ибо несколько другая задача (это само собой сделано, ясен пень, но не решает п.1)

O>Пункт 1 успешно решается вызовом Shell_NotifyIcon в цикле с некоторой задержкой,

O>до тех пор, пока функция не вернет TRUE. Например, по WM_TIMER.
Чуток иначе сделал, через фоновый поток
Автор: Carc
Дата: 28.11.12
. Но в том случае пофиг было. Т.к. фоновых потоков и так хватало в софтине, и они синхронизировались с гуи-потоком по любому. Так что лишний поток проблемы не создавал. Болтается в фоне, поспит-поспит — попросит гуёвый поток еще раз тыркнуться в трей. Прошло — отлично. Не прошло — еще поспит.

>P.S.

O>Кстати, в Windows 7 юзать трей уже не модно — там есть ITaskbarList3 и т.п.
Не уловил... А чем ITaskbarList3 решает\улучшает работу с треем? Почему "не модно"? Используют что-то другое?
O>И там аналогичные проблемы с отловом запуска/перезапуска таскбара — "TaskbarButtonCreated".
Aml Pages Home
Re[10]: Проверить/отловить доступность TaskBar - как?
От: okman Беларусь https://searchinform.ru/
Дата: 15.12.12 12:30
Оценка:
Здравствуйте, Carc, Вы писали:

C>А чем ITaskbarList3 решает\улучшает работу с треем? Почему "не модно"? Используют что-то другое?


По сравнению с треевой иконкой кнопка на таскбаре — более управляемое и в некоторых случаях более
наглядное в визуальном плане средство. Туда можно и оверлейную иконку впихнуть поверх основной, и
индикатор прогесса, и thumbnail, и кнопки. Жаль, что это работает только с Windows 7 и выше.
Re[10]: Проверить/отловить доступность TaskBar - как?
От: okman Беларусь https://searchinform.ru/
Дата: 15.12.12 12:37
Оценка:
Здравствуйте, Carc.

Забыл добавить, и это чуть ли не самое главное.
В Vista и выше все эти иконки по умолчанию скрыты в маленьком меню в трее,
если только пользователь явно не включит их в настройках меню "Пуск".
То есть, в общем случае, если надо пользователю о чем-то срочно моргнуть, иконка уже не подходит.
Re[12]: Проверить/отловить доступность TaskBar - как?
От: CEMb  
Дата: 17.12.12 06:00
Оценка:
Здравствуйте, Carc, Вы писали:

BI>>А у меня комп не выключается, спящий/ждущий режим. Случайно узнал об это проблеме. Перегружаю редко, пару раз замечал, что иконок у программ нет, не понял из-за чего. А тут ставил кучу обновлений с множеством перезагрузок и разул глаза.


C>Проблема много где проявляется. В немалой куче стороннего софта. А неудобно сильно. Прям хоть какую тулзу написать, чтобы в соседних программах правила сие дело.


Хорошая идея, кстати, и реализуется не сильно сложно Другое дело, что КПД у неё будет низкий.

Btw, я тут тоже решил покакать в ваш уютный вентилятор, и вспомнил, что у меня такая проблема была тоже, когда я встраивался в окно таскбара, мой код начинал собирать данные из системы по старту, подсаживал ShellTrayWnd, а за ним и explorer, одновременно я звал вставку иконки в трей. Всё это дело стабильно замирало на несколько секунд, вешая друг друга, что было вообще недопустимо для программы, которая должна вроде как наоборот ускорять и помогать. Проблему, помтится, решил, сделав под установку иконки отдельный сред. Регистрация-отслеживание сообщения всё равно надо, потому что таскбар может сдохнуть и заново родиться, тогда надо будет опять перевставиться, чего 50-60% программ, по моему наблюдению, не делают (и мои некоторые тоже), и приходится их искать спайем и выдёргивать в видимость
Re[13]: Проверить/отловить доступность TaskBar - как?
От: Carc Россия https://vk.com/gosha_mazov
Дата: 17.12.12 09:25
Оценка:
Здравствуйте, CEMb, Вы писали:

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


BI>>>А у меня комп не выключается, спящий/ждущий режим. Случайно узнал об это проблеме. Перегружаю редко, пару раз замечал, что иконок у программ нет, не понял из-за чего. А тут ставил кучу обновлений с множеством перезагрузок и разул глаза.


C>>Проблема много где проявляется. В немалой куче стороннего софта. А неудобно сильно. Прям хоть какую тулзу написать, чтобы в соседних программах правила сие дело.


CEM>Хорошая идея, кстати, и реализуется не сильно сложно Другое дело, что КПД у неё будет низкий.


CEM>Btw, я тут тоже решил покакать в ваш уютный вентилятор, и вспомнил, что у меня такая проблема была тоже, когда я встраивался в окно таскбара, мой код начинал собирать данные из системы по старту, подсаживал ShellTrayWnd, а за ним и explorer, одновременно я звал вставку иконки в трей. Всё это дело стабильно замирало на несколько секунд, вешая друг друга, что было вообще недопустимо для программы, которая должна вроде как наоборот ускорять и помогать. Проблему, помтится, решил, сделав под установку иконки отдельный сред. Регистрация-отслеживание сообщения всё равно надо, потому что таскбар может сдохнуть и заново родиться, тогда надо будет опять перевставиться, чего 50-60% программ, по моему наблюдению, не делают (и мои некоторые тоже), и приходится их искать спайем и выдёргивать в видимость

Сообщение сообщением — это само собой разумеется. Просто это другой use-case: "был-жил таскбар до добра наживал, да вдруг померъ"...

Поток я заводил в своем случае вместо WM_TIMER как советовал omonim, исключительно из архитектурных соображений. Та самая тулза писана на чистом WinAPI, поэтому там хоть и пара классов для удобства разработки, но все равно все сводится к мрачному switch-case в WindowProc. Поэтому лазить в нее с правками совсем скучно. Куда как проще было воткнуть поток, который по своему коду будет практически автономен.

С той лишь разницей, что у меня этот фоновый поток не сам ставил иконку, а дергал через SendMessage+WM_APP+xxx основной — чтобы тот еще раз попытался воткнуться в трей. А уж основной поток знал, надо-не-надо, что вернуть в случае успеха и.т.д. В общем исключительно вопрос инкапсуляции и только.

Плюс вопросов синхронизации потоков вообще не возникало. В той софтине фоновых потоков уже хватает, которые чего-то там в фоне готовят_данные\делают\пасут_изменения_настроек\и_прочия_и_прочия. Поэтому синхронизация уже давным-давно вылизана до идеала. Поэтому, как не забавно, добавить поток и синхронизовать его это буквально пара строк, чем мутить код в switch\case в WindowProc...

Проще говоря, не настаиваю на правильности отдельного потока. Идея исключительно в том, чтобы отложить(+может быть потоврить) Shell_NotifyIcon+NIM_ADD. А уж как это делать, через поток, через таймер или еще как — вопрос исключительно конкретики.
Aml Pages Home
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.