> Поставить указатель в трей с помощью SetCursorPos в конец трея
> Задавая приращения по горизонтали, обойти указателем иконки в
> трее. При этом будут появляться ярлычки подсказок к иконкам...

А у меня панель задач вдвое выше и автоскрывается. Мало того, что её
показать надо, прыгнув мышью в самый низ экрана и подождав, так ещё и иконки

в трее в три ряда выстраиваются. Каким образом ты собрался все их обойти по
горизонтали? И это ещё при том, что XPя по умолчанию скрывает некоторые
"неактивные" достаточно долгое время иконки за эдакой стрелочкой, и чтобы их

увидеть, на неё тоже нажать надо. И при этом не забыть, что панель задач
может быть не только внизу, но и справа, слева или вверху, где юзеру
удобнее. А если она автоскрывается, то при "автопоказе" оно не обязательно
будет на переднем плане, а вполне может оказаться под какими-то другими
окнами, даже если выставлена опция "Отображать панель задач поверх остальных

окон" - как меня нервирует, кстати.
Ну и чтобы добить. Ждать над каждой иконкой, нужно неопределённое время,

так как частенько обработчик рабочего стола неизвестно чем занимается вместо

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

хотя остальная винда работает как ни в чём не бывало, и все мышиные и
клавиатурные пинки не возымевают никакого действия. По прошествии
полутора-двух минут, они друг приходят в себя и побыстрому обрабатывают всё
то, что им быто понапнуто за это время. Весело бывает понаблюдать...
Напрягает не меньше. Если кто знает лекарство или хотя бы причину такого
поведения, буду рад любой информации.
Так что ИМХО избранный тобою подход в корне неверен. Я в принципе
недолюбливаю всё то, что делается потём эмуляции действий пользователя, так
как программно всей изощрённости человеческого разума не проэмулируешь.
Особенно его экстраваннтности и индивидуальности. Посему начисто отвергаю
решения, основанные на mouse_event() и keybd_event() Да и в MSDN чётко
говорится, что они заменены (superseded). Ищи другие пути, не то запаришся
поддерживать свою программу - пользователи задолбают.
Вот начало. Окно панели задач относится к классу Shell_TrayWnd. Одно из
его дочерних окон имеет класс TrayNotifyWnd, а у него в свою очередь одно из

дочерних - класс SysPager, которое в свою очередь одним из дочерних окно
класса ToolbarWindow32 и с заголовком (в русской редакции XP!) "Область
уведомлений", в котором уже и прорисовываются иконки. Кнопка, которая
открывает скрытые "неактивные" иконки, имеет класс Button и является
дочерним окном непосредственно от панели задач. Хватит информации для
начала? Всю её я получил простым разглядыванием Spy++ из комплекта MS
DevStudio. Но её понятное дело можно получить и программно - EnumWindows(),
EnumChildWindows(), GetWindow(), GetWindowInfo(), GetClassName() итп Скорее
всего некоторые неопределённости останутся, но ИМХО значительно меньше и
более легко обходимые, чем я привёл вначале по твоему методу.

P.S. Чуть не забыл: mouse_event() и keybd_event() заменены на
SendInput()

--
С уважением, boroda

Номер выпуска : 5188
Возраст листа : 873 (дней)
Количество подписчиков : 546
Адрес в архиве : http://subscribe.ru/archive/comp.soft.prog.prog/msg/513477
Получить правила : mailto:comp.soft.prog.prog-rules@subscribe.ru
Формат "дайджест" : mailto:comp.soft.prog.prog-digest@subscribe.ru
Формат "каждое письмо" : mailto:comp.soft.prog.prog-normal@subscribe.ru
Формат "читать с веба" : mailto:comp.soft.prog.prog-webonly@subscribe.ru

> Если коротко, приложение не может заставить окно стать foreground,
> если пользователь работает с другим окном или открыто меню.
> В этом случае целевое окно станет активно и будет
> мигать в панели задач, но не откроется.

И это правильно. Помню, как меня бесило в 95-й, когда сидишь,
программируешь или документируешь "вслепую", а потом бросаешь взгляд на
экран и видишь, что уже с полминуты твои клавиатурные танцы направляются
неизвестно кому. MicroSoft как раз и пошла навстречу многочисленным
"пожеланиям" (наверное, имелись ввиду "посылания") пользователей. Теперь,
начиная с 98-й и NT_какой-то_там_SP, SetForegroundWindow() может вынести на
передний план окна только своего же процесса (или нити, не помню точно), а
также специально указанных, как доверенные. Вот как "доверить" - не скажу,
забыл, но точно помню, что в MSDNе видел. И доверение должно было
отрабатывать на стороне того приложения, КОТОРОМУ - а не КОТОРОЕ - будет
делать SetForegroundWindow(). Т.е. приложение само решает, кому ещё, кроме
себя, оно доверит выносить свои окна на передний план.
Есть вариант, когда наоборот, окно выносится на передний план, но фокус
ввода не меняется. Когда отрабатывает так, когда иначе, не знаю. По-моему,
по второму сценарию ведут себя диалоговые окна, а по первому, все остальные,

но не уверен.

--
С уважением, boroda

Номер выпуска : 5187
Возраст листа : 873 (дней)
Количество подписчиков : 546
Адрес в архиве : http://subscribe.ru/archive/comp.soft.prog.prog/msg/513453
Получить правила : mailto:comp.soft.prog.prog-rules@subscribe.ru
Формат "дайджест" : mailto:comp.soft.prog.prog-digest@subscribe.ru
Формат "каждое письмо" : mailto:comp.soft.prog.prog-normal@subscribe.ru
Формат "читать с веба" : mailto:comp.soft.prog.prog-webonly@subscribe.ru

Здравствуйте, Шистеров.
ВШ>> "Бесхитростных" - таких, которым "не приходит в голову" передать
ВШ>> серверу свой хэндл, а самим "смыться с места преступления"?-)))))
ШП> Именно :) Но и безхитростные при работе через СОМ-сервер ведут себя
ШП> плохо.

ВШ>> Можно конечно и без титула. Просто, если клиенты имеют одинаковый
ВШ>> класс (у делфийских проектов, например, это именно так), то серверу
ВШ>> придется попотеть, чтобы по одному имени класса понять, хэндл какого
ВШ>> окна ему "ловить".
ШП> В том-то и дело, что сервер не ищет Хэндлы. Они у него есть. он только
ШП> проверяет на существование. если не существует, то запускает заново -
ШП> это другая задача и она работает нормально.

ШП>>> Меня терзают сомнения, что виной всему сервер, как промежуточное
ШП>>> звено, связанное с обоими процессами.
ВШ>> Убейте меня, но я уверен, что если SetForegroundWindow не выводит
ВШ>> вперед нужное окно (и вообще никакое), значит ему передан неактуальный
ВШ>> параметр.
ШП> Хмм... Параметр это Хэндл окна. И функция срабатывает, только не
ШП> корректно. Приложение становится активным, только мигает в панели
ШП> задач, а на экран не выводится.

ВШ>> В принципе, Вы можете написать для проверки этого такое себе проверочное
ВШ>> приложение, в котором будет тикать таймер и внутри обработчика тиков
ВШ>> это приложение будет следить за окном клиента (которое не хочет
ВШ>> показываться). Только частоту тиков выбирете побольше.
ШП> Для проверки я сделал сом-сервер и 2 приложения-клиента. Эффект
ШП> тот-же. Причем приложения сами по себе ничего не делают, т.е. не
ШП> закрываются и не перезапускаются.

Ну тогда, действительно, остается попробовать BringWindowToTop.

> ШП>> Меня терзают сомнения, что виной всему сервер, как промежуточное
> ШП>> звено, связанное с обоими процессами.
> ВШ> Убейте меня, но я уверен, что если SetForegroundWindow не выводит
> ВШ> вперед нужное окно (и вообще никакое), значит ему передан неактуальный
> ВШ> параметр.
> Хмм... Параметр это Хэндл окна. И функция срабатывает, только не
> корректно. Приложение становится активным, только мигает в панели
> задач, а на экран не выводится.
>
Функция SetForegroundWindow довольно хитрая и в MSDN ей
посвящена обширная статья.

Если коротко, приложение не может заставить окно стать foreground,
если пользователь работает с другим окном или открыто меню.
В этом случае целевое окно станет активно и будет
мигать в панели задач, но не откроется.

Попробуйте BringWindowToTop.

Номер выпуска : 5185
Возраст листа : 873 (дней)
Количество подписчиков : 546
Адрес в архиве : http://subscribe.ru/archive/comp.soft.prog.prog/msg/513293
Получить правила : mailto:comp.soft.prog.prog-rules@subscribe.ru
Формат "дайджест" : mailto:comp.soft.prog.prog-digest@subscribe.ru
Формат "каждое письмо" : mailto:comp.soft.prog.prog-normal@subscribe.ru
Формат "читать с веба" : mailto:comp.soft.prog.prog-webonly@subscribe.ru

Здравствуйте, Вадим,

ВШ> "Бесхитростных" - таких, которым "не приходит в голову" передать
ВШ> серверу свой хэндл, а самим "смыться с места преступления"?-)))))
Именно :) Но и безхитростные при работе через СОМ-сервер ведут себя
плохо.

ВШ> Можно конечно и без титула. Просто, если клиенты имеют одинаковый
ВШ> класс (у делфийских проектов, например, это именно так), то серверу
ВШ> придется попотеть, чтобы по одному имени класса понять, хэндл какого
ВШ> окна ему "ловить".
В том-то и дело, что сервер не ищет Хэндлы. Они у него есть. он только
проверяет на существование. если не существует, то запускает заново -
это другая задача и она работает нормально.

ШП>> Меня терзают сомнения, что виной всему сервер, как промежуточное
ШП>> звено, связанное с обоими процессами.
ВШ> Убейте меня, но я уверен, что если SetForegroundWindow не выводит
ВШ> вперед нужное окно (и вообще никакое), значит ему передан неактуальный
ВШ> параметр.
Хмм... Параметр это Хэндл окна. И функция срабатывает, только не
корректно. Приложение становится активным, только мигает в панели
задач, а на экран не выводится.

ВШ> В принципе, Вы можете написать для проверки этого такое себе проверочное
ВШ> приложение, в котором будет тикать таймер и внутри обработчика тиков
ВШ> это приложение будет следить за окном клиента (которое не хочет
ВШ> показываться). Только частоту тиков выбирете побольше.
Для проверки я сделал сом-сервер и 2 приложения-клиента. Эффект
тот-же. Причем приложения сами по себе ничего не делают, т.е. не
закрываются и не перезапускаются.

Hello comp,

Приходится писать проект по автоматизации закачки из Инета.
Подключение к Инету должно происходить через оптимизатор модема
(скорость при этом, действительно, увеличивается на 20-50%). Сам
оптимизатор сидит в трее, и соединение инициализируется щелчком по его
иконке. Самое интересное, что по другому заставить заработать этот
оптимизатор нет.
Вот я и думал организовать процесс вызова так:
Поставить указатель в трей с помощью SetCursorPos в конец трея
Задавая приращения по горизонтали, обойти указателем иконки в
трее. При этом будут появляться ярлычки подсказок к иконкам. Вот их-то
и нужно проверять. Наблюдая за изменениями в "оконной среде" системы через
WinSight, я увидел, что эти ярлычки "привязываются" к popup-окнам с
именем класса tooltips_class32. Как я понимаю, это значит, что если с
помощью FindWindow и GetWindow обойти все окна с таким именем класса, то
GetWindowText может определить текст ярлыка, и таким образом моя прога
определит, над нужной ли иконкой находится мышь. Ну а спровоцировать
мышь на щелчок - уже дело техники.
Да вот, что-то не получается у меня отыскать в списке окон окно с
ярлычком. Я думаю, может моя прога не успевает по времени "ухватиться"
за этот ярлык. Или я концептуально ошибаюсь?

Здравствуйте, Шистеров.

Friday, February 10, 2006, 5:39:51 AM, you wrote:
ВШ>> Я к чему это говорю - такое поведение сервера
ВШ>> довольно странно. Ведь тот, кто выводит чужое окно, должен сам
ВШ>> определить хендл этого окна и без промедлений вывести это окно вперед
ВШ>> - пока нужное окно имеет этот хэндл.
ШП> Так прекрасно срабатывает без СОМ-сервера, правда на простеньких
ШП> тестерах.
"Бесхитростных" - таких, которым "не приходит в голову" передать
серверу свой хэндл, а самим "смыться с места преступления"?-)))))

ВШ>> В Вашем случае было бы намного
ВШ>> лучше, если бы серверу передавали имя_класса и/или титульную строку
ВШ>> окна, а сервер сам находил хэндл этого окна, проверял бы его на
ВШ>> неравность нулю и тут же выводил это окно вперед.
ШП> Ну-у, на счет титульной строки не соглашусь. А проверку на наличие
ШП> окна сервер делает.
Можно конечно и без титула. Просто, если клиенты имеют одинаковый
класс (у делфийских проектов, например, это именно так), то серверу
придется попотеть, чтобы по одному имени класса понять, хэндл какого
окна ему "ловить".

ШП> Меня терзают сомнения, что виной всему сервер, как промежуточное
ШП> звено, связанное с обоими процессами.
Убейте меня, но я уверен, что если SetForegroundWindow не выводит
вперед нужное окно (и вообще никакое), значит ему передан неактуальный
параметр.
В принципе, Вы можете написать для проверки этого такое себе проверочное
приложение, в котором будет тикать таймер и внутри обработчика тиков
это приложение будет следить за окном клиента (которое не хочет
показываться). Только частоту тиков выбирете побольше.

Здравствуйте, Вадим,
ВШ> Скажите, а Вы пишете саму серверную часть?
Да.

ВШ> Я к чему это говорю - такое поведение сервера
ВШ> довольно странно. Ведь тот, кто выводит чужое окно, должен сам
ВШ> определить хендл этого окна и без промедлений вывести это окно вперед
ВШ> - пока нужное окно имеет этот хэндл.
Так прекрасно срабатывает без СОМ-сервера, правда на простеньких
тестерах.

ВШ> В Вашем случае было бы намного
ВШ> лучше, если бы серверу передавали имя_класса и/или титульную строку
ВШ> окна, а сервер сам находил хэндл этого окна, проверял бы его на
ВШ> неравность нулю и тут же выводил это окно вперед.
Ну-у, на счет титульной строки не соглашусь. А проверку на наличие
окна сервер делает.

Меня терзают сомнения, что виной всему сервер, как промежуточное
звено, связанное с обоими процессами.