Qt-interest Archive, January 2007
Plugging into the qt event loop, mixing roguewave zap and qt
Message 1 in thread
Hallo,
We'd like to migrate from Roguewave's zap to qt. Unfortunately, we cannot
just replace zap, but we rather intend to use qt in our existing
applications and migrate step-by-step.
What is the best way to do this? Do there exist solutions for this already?
I successfully managed to compile, link and run an application with qt and
zap libraries. The event handling does require special care, though.
We've been looking at the source code of qt a bit. In
QEventDispatcherX11::processEvents(), for instance, one could hook in to
delegate X11 events to the zap event loop.
A (quite knowledgable) colleague of mine suggested to use XtAppAddInput to
install a callback to catch all events qt can't handle, i.e. those
destined for all zap widgets.
We would be grateful for hints to put us in the right direction.
Greetings,
thomas
P.S.: We have to do all this on Windows as well!!
--
[ signature omitted ]
Message 2 in thread
Thomas Mittelstaedt wrote:
> Hallo,
>
> We'd like to migrate from Roguewave's zap to qt. Unfortunately, we
> cannot just replace zap, but we rather intend to use qt in our
> existing applications and migrate step-by-step.
> What is the best way to do this? Do there exist solutions for this
> already?
>
> I successfully managed to compile, link and run an application with qt
> and zap libraries. The event handling does require special care, though.
> We've been looking at the source code of qt a bit. In
> QEventDispatcherX11::processEvents(), for instance, one could hook in
> to delegate X11 events to the zap event loop.
> A (quite knowledgable) colleague of mine suggested to use
> XtAppAddInput to install a callback to catch all events qt can't
> handle, i.e. those destined for all zap widgets.
>
Subclass QApplication and reimplement:
bool x11EventFilter(XEvent* event) on X11
bool winEventFilter(MSG* msg, long* result) on Win32
These will get you the native events before they get processed by Qt.
If you return true then the event is considered handled and Qt will not
process that event.
--Justin
begin:vcard
begin:vcard
fn:Justin Noel
n:Noel;Justin
org:ICS;Engineering
adr:;;54B Middlesex Trpk;Bedford;MA;01730;USA
email;internet:justin@xxxxxxx
title:Sr. Consulting Engineer / Certified Qt Instructor
tel;work:(617) 621-0060
url:http://www.ics.com
version:2.1
end:vcard
Message 3 in thread
Am 24.01.2007, 15:58 Uhr, schrieb Justin Noel <justin@xxxxxxx>:
> Thomas Mittelstaedt wrote:
>> Hallo,
>>
>> We'd like to migrate from Roguewave's zap to qt. Unfortunately, we
>> cannot just replace zap, but we rather intend to use qt in our
>> existing applications and migrate step-by-step.
>> What is the best way to do this? Do there exist solutions for this
>> already?
>>
>> I successfully managed to compile, link and run an application with qt
>> and zap libraries. The event handling does require special care, though.
>> We've been looking at the source code of qt a bit. In
>> QEventDispatcherX11::processEvents(), for instance, one could hook in
>> to delegate X11 events to the zap event loop.
>> A (quite knowledgable) colleague of mine suggested to use
>> XtAppAddInput to install a callback to catch all events qt can't
>> handle, i.e. those destined for all zap widgets.
>>
>
> Subclass QApplication and reimplement:
> bool x11EventFilter(XEvent* event) on X11
> bool winEventFilter(MSG* msg, long* result) on Win32
>
> These will get you the native events before they get processed by Qt.
> If you return true then the event is considered handled and Qt will not
> process that event.
>
> --Justin
Well, thanks for the hint. On Unix, at least, we tried something
different, using QSocketNotifier insteead.
zapNotifier = new QSocketNotifier( ConnectionNumber( app->display() ),
QSocketNotifier::Read );
// now connect to updateZap
QObject::connect( zapNotifier, SIGNAL(activated(int )),
this, SLOT(updateZap()) );
And in the updateZap() method, we do a app->flushMessageLoop();, where app
is the global roguewave zApp application instance.
Early tests with two dialogs, one qt, one zapp, showed that this works.
See also http://dot.kde.org/1073668213/.
thomas
--
[ signature omitted ]
