Так я думал когда увидел в wx-mail-list упоминание EVT_CHAR_HOOK. В доке про этот эвент ничего нет, но порывшись в гугле и поэкспеременитровал - я понял что его обработчик получает все нажатия клавиш для окна перед тем как они будут обработанны дочерними контролами. И возрадовался. Дело в том что я люблю так хоткее делать, под мфц это было PreTranslateMessage, под wxWidgets найденный вариант был - вся работа в обработчике EVT_KEY_DOWN и connect для (почти) каждого контрола на форме
m_Note->Connect(wxID_ANY, wxEVT_KEY_DOWN, wxKeyEventHandler(MainFrame::OnKeyDown), (wxObject*)NULL, this);
А поскольку коннкетить каждый контрол для сложного окна не самое приятно времепрепровождение, то я легко возбудился увидив EVT_CHAR_HOOK. И действительно коннекты уже не нужно, обработчик вызывается автоматом. Проблемы вылезли через пару дней:(. Первое по esc приложение "прячется" в трей - в новом варианте, если при открытом меню нажать еск, приложение спрячется а меню останется висеть:) Те хоткеи обработка которых зависила от выбранного в данный момент окна - то же в пролете.
Вообщем не получилось, хотя возможно стоит использовать EVT_CHAR_HOOK для ряда глобальных хоткеев (хотя с этим и меню справляется), а EVT_KEY_DOWN оставить для более специфических вещей.
2 комментария:
А ты не пробовал отправлять сообщение дальше по петле сообщений (т.е. делать Skip)? И если пробовал, то не пробовал ли ты на нужное нажатие клавиши не сразу сворачивать приложение в трей, а класть в очередь сообщений сообщение о сворачивании (свое собственное user-defined), а уже в его обработчике сворачивать программу?
Нет не пробывал, посколько по логике все равно не подходит. Если юзер при открытом меню - нажал еск, то дожно спрятатся только меню, а я не должен обрабатывать этот еск. В EVT_CHAR_HOOK нет (я не нашел) возможности определить для меню этот еск или нет...
Точно также некоторые другие глобальные хоткеи имеют некоторую привязку к контролам, вообщем мне не подошло это.
Отправить комментарий