Микроблог про wxWidgets

Не приходят, вообще. Приложение с AUI. Куда копать?

Так я думал когда увидел в wx-mail-list упоминание EVT_CHAR_HOOK. В доке про этот эвент ничего нет, но порывшись в гугле и поэкспеременитровал – я понял что его обработчик получает все нажатия клавиш для окна перед тем как они будут обработанны дочерними контролами. И возрадовался. Дело в том что я люблю так хоткее делать, под мфц это было PreTranslateMessage, под wxWidgets найденный вариант был – вся работа в обработчике EVT_KEY_DOWN и connect для (почти) каждого контрола на форме

Полюбуйтесь на это  – http://sourceforge.net/tracker/index.php?func=detail&aid=1428691&group_id=9863&atid=109863 . Багу больше 2x(!) лет, тянется еще с прошлого стабильного релиза. До сих пор не пофиксен. Status: Open.  А ведь есть специальные события даже  EVT_QUERY_END_SESSION и EVT_END_SESSION

Потратил полдня включая\выключая комп что бы найти приемлимый порядок команд для того что бы заставить его корректно выходить при выключении компа и сохранять настройки. И вчера уже собираясь выложить первую бету народу, обнаружил что под win2K не работает все равно. Мало того что не работает, так еще и подвисает при выходе. Сейчас опять буду е****я что бы работало везде.

Эхх, клонирую свою MFC программу под wxWidgets. Необходимо находясь в эдит контроле иметь возможность навигации по соседнему дереву, там я  просто просто в PreTranslateMessage в эдите отлавливал alt+стрелки\Page Down\UP менял обьект у события и форвадил дереву для обработки. На wx сделать не получалось, спросил в wx-users at lists.wxwidgets.org, в ответ от Vadim Zeitlin  получил

There is no way to make this work with native controls (such as wxTreeCtrl
under MSW): they have no idea about wx events so sending them to those
controls will obviously never do anything. We thought a few times in the
past to provide a way to generate a native keyboard message from e.g.
wxKeyEvent but this has never been done. If you feel like trying to do it,
it would certainly be welcome. Otherwise you will have to handle the keys
yourself manually (i.e. checks for arrow up and select the appropriate item
and so on).

Настроение с утра испортил:)

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

Будем копать дальше, гда наша не пропадала:)

В обработчике wxWindowDestroyEvent окно уже какое-то полудохлое, такое ощушение что еще не совсем умерло, но уже попахивает. При IsMaximized() получаем AV. Так что MFCшники бросайте привычку делать что-то в OnDestroy, дружно юзаем деструктор.

This event is sent just after the actual window associated with a wxWindow object has been created. Since it is derived from wxCommandEvent, the event propagates up the window hierarchy.

Обратите внимание на выделенное. Если хотите использовать этот событие для дополнительной инициализации диалога, по аналогии с OnInitDialog в MFC, то учтите: обработчик OnCreate для wxWindowCreateEvent вызывается много раз, первый раз после инициализации фрейма, а потом после создания каждого контрола. Так что или выберите другое место для дополнительной инициализации или предохраняйтесь:

if(event.GetEventObject()==this)

{

….

}

Не радует меня система сообщений в wxWidgets, приложение получает wxIconizeEvent и wxMaximizeEvent уже постфактум. Ни запретить действие, ни выполнить свой код перед тем как окно будет свернуто\развернуто – нельзя.

Не смотря на то что в документации написано
An event being sent when the frame is maximized or restored.

и

An event being sent when the frame is iconized (minimized) or restored.

Приходит только после максимизации\минимизации. При возвращении к нормальным размерам – неприходит. Под маком вроде вообще не должно приходить, так что пытатся его использовать наверное не стоит – хоть мне приходится.