Hello.
We have some strange problem running GTK(mm) app on Win32.
Not always, but on few workstations our application stuck forever on
handling window events like WM_MOVE (3) or WM_SIZE (5), that because
they never end in event queue, so, PeekMessageW always returns same
message (or few messages depending on number of opened GTK windows
affcted).
This usually happens when user double click on window title
(maximize/restore) and there is TreeView widget being updated.
Update is initiating from one thread (spontaneously), and data for tree
is collecting in second thread, at the end signal (DispatchNotifier) is
emitting to the main thread where actual widget update is happening.
When we block those spontaneous updates, everything seems to work
properly. Also, we never had such problems on Linux, neither on most
Win32 workstations (with different hardware and OS/Software versions).
The main questions:
1. Is it know issue?
2. Is there any way to avoid this?
There is the function where peek message loop never ends
(gdkevents-win32.c):
void
_gdk_events_queue (GdkDisplay *display)
{
MSG msg;
if (modal_win32_dialog != NULL)
return;
while (!_gdk_event_queue_find_first (display) &&
PeekMessageW (&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage (&msg);
DispatchMessageW (&msg);
}
}
As a "hack" we are storing message (MSG) and see if 100 next peeks
returns same msg structure, then we just break out of the loop.
The problem is when there is several opened GTK windows then msg buffer
will be not filled constanly with same message, but could vary as many
as number of these windows. So, the improved "hack" could slow down
event flow performance dramatically.
--
Andrew E. Makeev <andrew@xxxxxxxx>
Solvo Logistic
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
