Дополнение H: Обработка событий в wxWidgets.

Сейчас мы попробуем подробно осветить вопрос обработки событий в wxWidgets , включая все детали, опушенные когда мы об этом говорили в прошлый раз.
Когда приходит событие от оконной системы, wxWidgets вызывает функцию wxEvtHandler::ProcessEvent принадлежащую первому объекту окна с генерировавшего событие.
  
Рисунок H-1 демонстрирует порядок поиска в таблице, так как его выполняет ProcessEvent. Все это работает следующим образом:

1. Если объект находится в заблокированном состоянии (после вызова wxEvtHandler::SetEvtHandlerEnabled), функция сразу переходит к шагу №6. 

2. Если объект является окном (наследник класса wxWindow) ProcessEvent рекурсивно вызывает все валидаторы установленные для этого окна. В случае успеха, функция завершается.    

3. Иначе вызывается SearchEventTable для обработчика данного события. Если поиск не увенчался успехом, то поиск продолжается в таблице для базового класса, далее следующего базового класса, и так далее по все иерархии до тех пор пока соответствующий обработчик не будет найден или не закончится иерархия, в первом случае функция прекращает работу.

4. Поиск проходит вниз по всей цепочке обработчиков событий (обычно в ней всего один элемент). Функция завершается в случае, если найден подходящий обработчик.

5. Если объект наследник wxWidnow и событие должно быть распространено (обычно распространяются только события типа wxCommandEvent), ProcessEvent рекурсивно вызывает обработчики родительских окон. В случае возврата true, функция прекращает работу.

6. И наконец, вызывается ProcessEvent объекта приложения.
 
Рисунок H-1. Поток обработки события

Обратите особое внимание на пятый шаг. Люди часто приходят в замешательство от этой мощной и гибкой возможности системы обработки событий в wxWidgets или просто игнорируют ее. Говоря другими словами, события с установленным флагом, разрешающим распространение (обычно это достигается путем прямого или косвенного наследования от wxCommandEvent) путешествуют вверх по иерархии окон, от дочернего к родительскому окну, до тех пор пока не будет достигнут максимальный уровень распространения или не найдется подходящий обработчик, который НЕ вызовет Skip().   
 

Когда командное событие распространяться в верх к родительскому окну, распространение прекращается по достижению родительского диалога, если он есть. Это гарантирует что вы не рискуете получить неожиданное событие от контролов вашего диалога (которые скорее всего будут оставлены диалогом не обработанными по сколько он ничего не знает о них) выше написанное справедливо для модального диалога. Однако, события свободно распространяются между фреймами. Причиной для такого выбора послужило то, что обычно приложение имеет всего несколько фреймов, и связи ребенок – родитель вполне осознаются программистом. В то время как в сложной программе, может быть весьма сложно или даже невозможно, отследить все используемые диалоги (помните что некоторые их них вполне могут создаваться самой библиотекой). Если вам по каким-либо причинам необходимо иное поведение, вы можете явно вызвать SetExtraStyle(wxWS_EX_ BLOCK_EVENTS), чтобы предотвратить распространение событий за пределы данного окна, или вы можете сбросить этот флаг для диалогов, где он установлен по умолчанию.

Основные события окна (изменения размера, движения, события отрисовки, мыши, клавиатуры и так далее) посылаются только окну. События, имеющие значения более высокого уровня или события генерируемые самим окном, к примеру, нажатия на кнопки, выбор меню, раскрытия ветви дерева и т.д. являются командами и отсылаются родительскому оку, на случай если оно заинтересованно в их специальной обработке. 

Учтите, что вы вполне можете заместить стандартную функцию ProcessEvent для перенаправленния обработки сообщений. Это, к примеру, сделано для в части библиотеки отвечающей за реализацию архитектуры документ-представление, для того что бы позволить размещение обработчиков событий как в классе документа, так и в классе представления. Для определения, является ли событие командой (скорее всего вы хотите перенаправлять только командные события) в целях эффективности вы можете использовать wxEvent::IsCommandEvent вместо, использования достаточно медленной системы типов времени выполнения.    

Breakpoint 2, BegUtils::GetImageFromZipResource (pathURL=…, fileName=…, type=wxBITMAP_TYPE_PNG) at /media/data/work/Flashnote/src/Utility/begutils.cpp:166
/media/data/work/Flashnote/src/Utility/begutils.cpp:166:4941:beg:0x82977e3
>>>>>>cb_gdb:
> info locals
warning: static field’s value depends on the current frame – bad debug info?
/build/buildd/gdb-7.2/gdb/findvar.c:427: internal-error: read_var_value: Assertion `frame’ failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Если определения строки нет, то заходил, но падал стоило провести курсором над параметром функции – строке. Вообщем дебажить было вообще невозможно.

Решение такое:

CodeBloks -> Settings -> Compiler and debugger settings -> Debugger settings -> И там в первый едит бокс добавляем строку source  /media/data/const/wxWidgets/misc/gdb/print.py

После чего падения прекращаются, и о чудо, отладчик начинает показывать значение wxString. Жизнь сразу становится много лучше:)

Еще почитать можно тут Pretty printing wxStuff in gdb и тут

Пытался использовать средства gtk (или posix, или чье это там), типа

#include <stdio.h> // for File I/O
#include <signal.h> // for signals
#include <unistd.h> // for sleep()

void handler(int sig)
{
        /* Just print to stderr and redirect 2>> test.txt in the shell */
    fprintf(stderr, "got %d\n", signal);

    signal(sig, handler); // let signal be caught again
}

int main()
{
    signal(SIGTERM,handler);
    signal(SIGINT,handler);
    signal(SIGQUIT, handler); // Maybe we're getting QUIT first?
    signal(SIGHUP, handler); // If the terminal closes, we might get this
    signal(SIGPIPE, handler); // Don't know why we'd get this, but check anyway
    while(1) // loop forever with most signals trapped, impolitely waiting for a kill -9 ;)
    // run
}

Не фига, когда руками прибиваю приложение Ctrl+c в терминале или kill … срабатывает, когда вырубаю систему нет, сообщения не получаю. В инете все пишут тоже самое не работает.  Code::Blocks тоже не сохраняет данные, если что-то изменить и сделать logout.  

Получается линукс, или убунта, или гном не дает возможность приложению узнать что сессия завершается и корретно завершить работу, сохранив данные. Вот вам и Linux with a human face

Есть правда какой-то EggSMClient в виде сорцов, LGPL, его например использует GEdit и молодец, корректно обрабатывает все. Но что-то про EggSMClient ни упоминаний толком, ни документации – особенно ничего не находится, а так разобратся без бутылки не получается. Печально все это

Про Qt:

1. На Qt писать быстрее и проще (субьективно и смотря что)

2. Написанное под виндо в течении 3 месяцев запускается на макоси после часа работы.

3. Приложения не родные

4. Приложения здоровые.

Про wxWidgets:

1. Писать вполне нормально, хотя может и не так гладко как на Qt

2. Результат выглядит роднее

3. Бинарников по паре сотен килобайт не получается, но и не десятки метров как у Qt.

4. Запуск под макосом – требует гораздо большего количества нервов, времени и напильников.

Для этой программы я после 10 дней на вх, выбрал Qt (совсем его тогда не зная), и не пожалел. Для своих Clipdiary и Flashnote я все таки считаю что wx не плох, хотя следует признать что первая программа уже продается под МакОС, а вторая и третья только в далекой перспективе:)

В общем – как всегда для конкретной задачи, нужен конкретный инструмент.

А еще, учитывая последний маневр Нокии, есть вероятность что развитие Qt тормознется, об этом стоит тоже думать….

Шаг первый – правильные контейнеры.

Код использовал списки, при портировании я их и заменил на QList. Но в принципе списки не самый быстрый контейнер для простых операций. Первое что я сделал заменил на QVector. Автозаменой, получил прирост в 30%.

Шаг второй – правильные методы доступа.

В поисках что бы еще улучшить, случайно наткнулся в документации на следующее

For read-only access, an alternative syntax is to use at():

at() can be faster than operator[](), because it never causes a deep copy to occur.

У нас в контейнере хранились просто int’ы, ничего более сложного, поэтому чудес я не ожидал. Но произошло чудо:)

Замена всего одной строчки в коде вида

Q_FOREACH(QList<int> pf, paths_father)

{

Q_FOREACH(QList<int> pm, paths_mother)

{

if (pf[0] != pm[0]) continue;

Ориганалы можно посмотреть тут и тут.

Правда прикольно?:)