Опять системный трэй

[SLIM]

Не могу понять, что не так.
Уже даже скачал пример посмотреть - у них работает, у меня нет.

Добавляю иконку в трэй, а там пустое место вместо значка, хотя под иконку место выделено. Пробовал и из-под IDE и из скомпилированного проекта...все попусту.
Структуры вроде как все в порядке. Вот код.

Код: Выделить всё

Private Declare Function Shell_NotifyIcon Lib "shell32.dll" Alias "Shell_NotifyIconA" _
                    (ByVal dwMessage As Long, lpData As NOTIFYICONDATA) As Long

Const NIM_ADD = &O0
Const NIM_MODIFY = &O1
Const NIM_DELETE = &O2


Const NIF_MESSAGE = &O1
Const NIF_ICON = &O2
Const NIF_TIP = &O4
Const WM_LBUTTONDOWN = &O201


Public Type NOTIFYICONDATA
    cbSize As Long
    hWnd As Long
    uID As Long
    uFlags As Long
    uCallbackMessage As Long
    hIcon As Long
    szTip As String * 64
End Type


Public T_NID As NOTIFYICONDATA





Public Sub InitNIDType()
    T_NID.cbSize = Len(T_NID)
    T_NID.hWnd = Me.hWnd
    T_NID.uID = Me.hWnd
    T_NID.hIcon = Me.Icon
    T_NID.szTip = Left$("Slim tray", 63) & Chr$(0)
    T_NID.uCallbackMessage = WM_LBUTTONDOWN
    T_NID.uFlags = NIF_MESSAGE Or NIF_ICON Or NIF_TIP
End Sub



Private Sub Form_Resize()
    If Me.WindowState = vbMinimized Then
        Shell_NotifyIcon NIM_ADD, T_NID
        Me.Visible = False
    End If
End Sub

Вот что не так?

[iGrok]

Кинь лучше проект. А то тут фиг поймёшь. Если место есть, и на клики реагирует(а реагирует?), тогда может что-то не в порядке с Me.Icon ?

[Хакер]

Const WM_LBUTTONDOWN = &O201

Не правда.

[SLIM]

Кинь лучше проект. А то тут фиг поймёшь. Если место есть, и на клики реагирует(а реагирует?), тогда может что-то не в порядке с Me.Icon ?

Ну я могу кинуть, но толку то.Я выгреб с проекта все что есть касаемо Shell_NotifyIcon.
Возврат из трэя я еще не далал вообще, поэтому реагировать ни на что не будет. Но система дает сообщения иконке - она мигает.
Иконка Me.Icon тоже в порядке - смотрел в PE Explorer -все на месте. Я сначала подумал что из-под IDE не могу загрузить - мол ресурсов то еще как бы нет. Но не то...

[Хакер]

Иконка Me.Icon тоже в порядке - смотрел в PE Explorer -все на месте. Я сначала подумал что из-под IDE не могу загрузить - мол ресурсов то еще как бы нет. Но не то...

Интересно, что ты им смотрел? Ибо иконки форм не помещаются в ресурсы...

[SLIM]

Прошу извинения у тех кто решился мне помочь
Помог Хакер тыкнув меня носом в использование приватных констант в модуле.

Вот дятел...

[Хакер]

Помог Хакер, ткнув <...>
Вот дятел...

[Куков]

Ребята, прошу помочь мне, видать за лето отупел и ничего не могу понять...

Скачал пример где есть класс TrayIcon, и я никак не могу разобратся как отлавливать нажатия по иконке трея

Форма

Код: Выделить всё

'ловим ивенты на форме
Private Sub Form_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)

   'передаем данные в объект
      cTray.CallEvent X, Y
     
End Sub

'ивент срабатывает при действиях на иконке в трее
Private Sub cTray_OnIcon(MouseButton As Integer)
   'обладочная информация
      Debug.Print MouseButton
   
   'левый двойной клик
      If MouseButton = TRAYICON_MOUSE_LEFTDBLCLICK Then MsgBox "LeftDoubleClick on TrayIcon"
   'отжатие правой кнопки мыши
      If MouseButton = TRAYICON_MOUSE_RIGHTUP Then cTray.CallPopupMenu Me, pmnuTray, 2, , , mnuHello
     
End Sub

Модуль класса

Код: Выделить всё

'вызвать ивент
Public Sub CallEvent(X As Single, Y As Single)
   'проверка, было ли действие по окну или по иконке в трее
      If Y Then Exit Sub
     
   'получаем тип действия
      Dim MouseButton As Integer
      MouseButton = (X And &HFF) / Screen.TwipsPerPixelX
   
   'генерируем ивент
      RaiseEvent OnIcon(MouseButton)
     
End Sub

В примере все работает, когда я пытаюсь сделать тоже самое (не используя данный класс) тыкаю курсором по иконке трея а в ответ фиг, ставил брикпоинты, вообщем процесс Form_MouseDown даже не затрагивается.

Собственно вопрос в следующем: как мне отслеживать действия на иконке трея, скажем клик?

[alibek]

Посмотри, как в классе ставится нотификация.

[Куков]

Спасибо большой человек, я нашел свою ошибку - я забыл поставить флажок NIF_MESSAGE, хех буду надеятся что в следуюший раз я буду повнимательней.

[SLIM]

Итак, проблемы продолжаются...

Свернуть в трэй мы смогли, теперь разворачиваем

Гугл мне дал сотню страничек с одним и тем же примером, который меня не очень то устраивает, так как документации я к этим примерам не нашел.
Мой товарищ Хакер помог мне в решении проблемы, и решение пошло в русло sub-clsssing-а. Я если честно никогда этим именно на VB не занимался, поэтому попотеть пришлось.

Итак, помолясь с MSDN-ом мы начали курить документацию по Shell_NotifyIcon, откуда попали к NOTIFYICONDATA Structure, где собственно и прописывается информация, которая меня интересует - как же вернуть прежний вид приложения.
Самое важное поле для меня было uCallbackMessage, в него мы запишем сообщение-маркер, благодаря которому мы узнаем что хотим показать окно.
Ок, MSDN пишет, что мол

the wParam parameter of the message contains the identifier of the taskbar icon in which the event occurred

Ну id у меня hwnd окна, значит wparam посланного сообщения будет содержать hwnd окна.

Ну я как последний дятел в sub-class-ге сразу решил в sub-window-proc обрабатывать сообщения, переданные мышью, а уже после отлова сообщения смотреть wParam. Вот дятел чесслово.

На самом деле все сообщения будут отправляться окну, и конечно же они могут быть не только сообщения мыши. Могут быть вообще нестандартное сообщение, а юзерские. Соответственно я взял WM_USER с неважно каким смещением.

Потом меня тыкнули в строчку в MSDN

The lParam parameter holds the mouse or keyboard message associated with the event

Т.е. сообщение будет в lParam.

Итак
1. Спускаем приложение в трэй
2. Запускаем свою самодельную WindowProc
3. Обрабатываем сообщение WM_USER + ... (после чего обязательно вызываем родную WindowProc; если сообщение не WM_USER, тоже вызываем обычный WindowProc)
4. Если отловили WM_USER, просматриваем lParam на предмет содержания в нем сообщения, которое нам так необходимо, в моем случае WM_LBUTTONDOWN
5. Показываем окно
6. Вызываем родную WinProc

Клик на иконке отработан, а вот с показам окна проблема.

Тут хочется вспомнить украинских комедийных артистов, которые сказали "И что я только с ним не делала..."

Я и ShowWindow юзал, и сообщение SHOW слал, и стиль окна SetWindowLong-ом менял, и по совету Хакера SetWindowPlacement даже мучал.
Но вот не хочет появляться и все тут.
Самым удачным вариантом был конечно SetWindowPlacement, я хотя бы мог восстановить по структуре WINDOWPLACEMENT прежние координаты и стили окна до сворачивания, и окно как бы появлялось на панели задач, но я его не вижу. В W7 есть мини-просмотр окна, но там только значёк приложения. Т.е. окно просто тупо не прорисовывается.

Кто подскажет почему?

[iGrok]

Что-то ты странное пишешь. Кинь проект, а?

[Viper]

Где-то в районе Кирпичей есть вполне работоспособный пример, зачем велосипед то изобретать?

[iGrok]

В кирпичах, кажись, был без WindowProc - через сообщения мыши..

Вот тут со своей WinProc..

[Alexanbar]

Приложение может посылать в трей несколько иконок. Соотвественно, у каждой иконки свой ID.
ucallbackmessage позволяет посылать приложению нужные данные, в частности, чего там юзверь вытворяет с иконкой - кликает ли по ней, просто водит мышой, или ещё чего.

ПОказаывать окно приложения должен не трей, а само приложение! При условии, его об этом правильно попросили.

[SLIM]

Что-то ты странное пишешь. Кинь проект, а?

Возможно странное. Я и написал чтобы разобраться странное или нет. Приаттачил прект

Где-то в районе Кирпичей есть вполне работоспособный пример, зачем велосипед то изобретать?

Не смотрел в кипичах, но если это то что я думаю, то этот вариант я отмел и сказал почему

В кирпичах, кажись, был без WindowProc - через сообщения мыши..

Вот тут со своей WinProc..

Посмотрел проект одним глазом. Что-то по-моему уже слишком замудрено для такой простой задачи. Есть плюсы, но у меня все попроще. Я просто опирался на первичные знания, которые получил когда писал первый проект на сях.

Приложение может посылать в трей несколько иконок. Соотвественно, у каждой иконки свой ID.

Ага, это конечно понятно. Но у меня пока что одна.

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

ucallbackmessage - это сообщение-маркер, которое помогает работать с обработкой сообщений. Ведь само сообщение содержится в lParam. Поэтому я юзаю свое юзерское сообщение.

ПОказаывать окно приложения должен не трей, а само приложение! При условии, его об этом правильно попросили.

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


З.Ы. Проект очень недоработан, поэтому прошу не бить сильно

[iGrok]

Приаттачил прект

Куда? =)

[SLIM]

Теперь сделал

[iGrok]

От же ж блин. Господин реально знает толк в извращениях.

Я тебе чего скажу-то. Ты ещё намучаешься со своим проектом, если тебе надо будет с иконкой что-то посложнее сделать.

Во-первых, у тебя после "показа" окна удаляется иконка. А при следующем сворачивании она ставится опять. НО! При следующем сворачивании у тебя ещё раз ставится сабклассинг. Классно, да? Как ты думаешь, после скрытия / показа, на второе скрытие у тебя упадёт проект, или нет? ,-)

Во-вторых, из-за чего не работает:
SubWindowProc = CallWindowProc(hPrev, hwnd, msg, wParam, lParam)
А то у тебя WinProc всегда возвращала 0. Соответственно, окно вообще ни на что не реагировало, кроме "закрыть" в Sysmenu.

В-третьих, для скрытия достаточно frmGlobal.Hide / для показа frmGlobal.WindowState = 0: frmGlobal.Show.

[SLIM]

От же ж блин. Господин реально знает толк в извращениях.

Ой спасибо...приятно то как ))

Я тебе чего скажу-то. Ты ещё намучаешься со своим проектом, если тебе надо будет с иконкой что-то посложнее сделать.

Возможно. Я не отрицаю.

Во-первых, у тебя после "показа" окна удаляется иконка. А при следующем сворачивании она ставится опять. НО! При следующем сворачивании у тебя ещё раз ставится сабклассинг. Классно, да? Как ты думаешь, после скрытия / показа, на второе скрытие у тебя упадёт проект, или нет? ,-)

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

Во-вторых, из-за чего не работает:
SubWindowProc = CallWindowProc(hPrev, hwnd, msg, wParam, lParam)

Блин...ну вот как так. Вот почему я постоянно на мелочах накалываюсь...А причина, может я просто недопонял что-то?

В-третьих, для скрытия достаточно frmGlobal.Hide / для показа frmGlobal.WindowState = 0: frmGlobal.Show.

Ну тут на любителя. Мог бы и так.


UPD::
Кстати, я тут таки нарыл твой старенький DBFView...с сабклассингом...ну это так...

А если после обработки сообщения менять алрес WinProc на родной. Какбы его узнать еще...пойду доки почитаю

[iGrok]

Но все же, SetWindowLong всего лишь устанавливает адрес функции. Ничего страшного, что он еще раз переустрановится. Ничего не должно упасть.

Теоретически да. =)
Но ты забыл, что при этом у тебя переписывается hPrev, и теперь вместо адреса оригинальной процедуры у тебя там адрес твоей.
Т.е. первый же вход в процедуру сабклассинга = бесконечный цикл и падение.

А причина, может я просто недопонял что-то?

Это вопрос? Или это так, лирическое отступление? ))

А если после обработки сообщения менять алрес WinProc на родной. Какбы его узнать еще...пойду доки почитаю

Гм. А что у тебя в hPrev после SetWindowLong оказывается по-твоему? =)

[SLIM]

Вот после таких постов я хочу стереть свой предыдущий )))

Да, действительно, hPrev попадает старый WinProc (иначе и не могло быть, как бы я вызывал тогда его).
Поэтому нужно возвращать старый адрес WP перед CallWindowProc, и в принципе должно все быт в порядке. Ну короче это все не так уж заморочено и сложно. Сделать можно. Я на этом не заморачивался.

Это вопрос? Или это так, лирическое отступление? ))

Это вопрос...был.
А потом я подумал, что ведь return WindowProc-а возвращается в DispatchMessage, а у меня он возвращает действительно только ноль и оно должно возвращать кое-какую информацию, отличную от нуля.

Какое мнение?

[iGrok]

Так. Ну во-первых, WindowProc может возвращать как ноль, так и что-то другое. Всё зависит от полученного сообщения.
При сабклассинге ты, грубо говоря, "влезаешь" в цепочку обработки сообщений перед оригинальным WP.
Что тебе нужно - то обрабатываешь. Если того требует твоя обработка, ты можешь сразу отдать "ответ" на сообщение, и не передавать его оригиналу. А можешь передать, и потом решать, что делать с ответом WP. Менять его, или отдать что-то своё.. Или передать как есть.

В любом случае сообщения, которые ты не обрабатываешь, ты должен отдать оригиналу, работая просто "переходником". Т.е. передал все параметры, получил ответ - вернул ответ тому, кто тебя вызвал. Это, собственно, и делает написанная мною строка.

Это по части лирики и возможных недопониманий "как оно работает".

Во-вторых:

Да, действительно, hPrev попадает старый WinProc (иначе и не могло быть, как бы я вызывал тогда его).
Поэтому нужно возвращать старый адрес WP перед CallWindowProc, и в принципе должно все быт в порядке. Ну короче это все не так уж заморочено и сложно. Сделать можно. Я на этом не заморачивался.

Нет. Ты не должен ничего "возвращать". Ты просто вызываешь "старую" WP этим самым CallWindowProc. Получаешь от неё ответ, и отдаёшь его "наверх".

Можно, конечно, при убирании иконки их трея снимать сабклассинг. Но это тот ещё гемор, ибо снять сабклассинг находясь с процедуре сабклассинга ты не можешь. И придётся что-то делать либо по таймеру, либо по какому-то другому событию. В любом случае это ромашка "упадёт-не упадёт".

Но, собственно, зачем?
Зачем снимать-ставить сабклассинг каждый раз?
Что тебе мешает поставить его в Form_Load, и снять при выгрузке?
Всего один раз поставить, и один снять. Ы?

[SLIM]

Так. Ну во-первых, WindowProc может возвращать как ноль, так и что-то другое. Всё зависит от полученного сообщения.

The return value is the result of the message processing and depends on the message sent - не больше не меньше. Значит может и ноль.

При сабклассинге ты, грубо говоря, "влезаешь" в цепочку обработки сообщений перед оригинальным WP.
Что тебе нужно - то обрабатываешь. Если того требует твоя обработка, ты можешь сразу отдать "ответ" на сообщение, и не передавать его оригиналу. А можешь передать, и потом решать, что делать с ответом WP. Менять его, или отдать что-то своё.. Или передать как есть.

В любом случае сообщения, которые ты не обрабатываешь, ты должен отдать оригиналу, работая просто "переходником". Т.е. передал все параметры, получил ответ - вернул ответ тому, кто тебя вызвал. Это, собственно, и делает написанная мною строка.

Это по части лирики и возможных недопониманий "как оно работает".

Ну тут я не совсем согласен.
Сабклассинг не просто прерывает цепочку, он продолжает дело оригинальной WinProc, не трогая оригинал. По идее после установки сабкласинга и забыть про оригинальный WinProc. Но ведь не будем же мы прописывать обработку всех сообщений системы. Нам нужно только одно. Вот его то мы и отлавливаем, а если не отлавливаем, то вызываем оригинальный WinProc, пусть она обработает сообщение. Оригинальный WinProc вызывается один единственный раз, и после этого управление переходит к самописной WP, а после ее выполнения возвращается в DispatchMessage, а от нее уже в цикл обработки сообщений. Цикл двинется дальше, и опять вызовет DispatchMessage, а тот вызовет WinProc, но на его месте уже будет мой WP, который по надобности опять вызовет оригинальный WP и т.д.

Просто перед сворачиванием в трэй нужно проверить hPrev, если там уже значение, то не меняем адрес WP ф-ии, тогда будет работать моя самописная.

Просто я к чему. Вот если просто вызвать оригинальную WP не передав return моей самописной, то соя самописная ф-я вернет чушь, и что будет дальше неизвестно (хотя известно наверное, надо порыться)


Исходя из этого и другие вопросы снимаются. Сабклассинг можно не снимать вовсе и запускать когда захочешь

UPD::
Хотя ты наверное в чем-то прав. Я сейчас запустил и вылетел на втором сворачивании. Надо подумать

UPDD::
А нет, все нормально. Не поставил условие проверки hPrev

[iGrok]

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

Да WP может возвращать всё, что угодно.
Да, сабклассинг - это полноценная "замена" WP. Если уж совсем хочется избавиться от родной WP, но не писать все сообщения самому, есть ещё DefWindowProc. Я, правда, не помню, что именно она обрабатывает. )

Если вызывать оригинальную, и не передать её ответ дальше, твоя WP всегда будет возвращать нули, и ты получишь окно, не реагирующее на сообщения. Поэтому у тебя и не получалось его развернуть.

Да. Если хочешь, можешь оставить как есть, только перед установкой сабклассинга проверять, нет ли уже адреса старой процедуры в hPrev.

Только один момент - "не снимать" всё-таки нельзя. Может, ничего плохого и не случится, но это уже чисто вопрос хорошего тона. Перед завершением приложения надо снимать сабклассинг. Как и уничтожать все созданные объекты, контексты и прочее.

Я только вот этого не понял:

Оригинальный WinProc вызывается один единственный раз, и после этого управление переходит к самописной WP

Даже если ты поместишь установку сабклассинга в Form_Load, у тебя оригиинальный WP вызовется никак не один раз. А много-много. Больше 20. Пока будет создаваться окно, и т.п. А уж если у тебя установка в процедуре сворачивания, так и вообще..

[SLIM]

Да нет iGrok, я не сколько не отрицаю и не противоречу.
Ты мне все верно указал, показал причину, ошибку, которую я пропустил.

Если вызывать оригинальную, и не передать её ответ дальше, твоя WP всегда будет возвращать нули, и ты получишь окно, не реагирующее на сообщения. Поэтому у тебя и не получалось его развернуть.

Ну да, просто я как-то пропустил этот факт.

Только один момент - "не снимать" всё-таки нельзя. Может, ничего плохого и не случится, но это уже чисто вопрос хорошего тона. Перед завершением приложения надо снимать сабклассинг. Как и уничтожать все созданные объекты, контексты и прочее.

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

Я только вот этого не понял:

SLIM писал(а):Оригинальный WinProc вызывается один единственный раз, и после этого управление переходит к самописной WP


Даже если ты поместишь установку сабклассинга в Form_Load, у тебя оригиинальный WP вызовется никак не один раз. А много-много. Больше 20. Пока будет создаваться окно, и т.п. А уж если у тебя установка в процедуре сворачивания, так и вообще..

Я имел ввиду что вот ситуация
1. В цикле обработки сообщений вызывается DispatchMessage
2. Тот вызывает WP, адрес которой в классе окна. Пусть там уже моя, самописная WP
3. Моя WP смотрит сообщение и вызывает оригинальный WP (не передает полное управление, а только на разик)
4. Оригинальная WP обработала сообщение, сделала return в мою WP
5. Моя WP сделала return в DispatchMessage
6. DispatchMessage вернула в цикл обработки сообщений
7. Цикл опять вызывает DispatchMessage
8. Тот опять мою WP
...
Видишь, моя WP теперь в круговороте, а оригинальная вызывается только раз когда нужно.
Вот о чем я говорил.

[iGrok]

Видишь, моя WP теперь в круговороте, а оригинальная вызывается только раз когда нужно.
Вот о чем я говорил.

Гм. Ну да.
Только обычно оригинальная вызывается не "разик", а большую часть времени, т.к. ты своей процедурой обрабатываешь только несколько сообщений, а всё остальное отдаёшь ей. Но это от тебя зависит естественно. Как захочешь(как нужно), так и сделаешь. )