From: Jason Wilkins <jason.a.wilkins@gm...> - 2011-02-24 05:18:09
I'm going to get a reputation as a strange hacker but I found an odd
bug. I have a semi-portable function openfilename which uses the
operating systems common file dialog to get a filename. I've
implemented it for windows console programs, regular windows programs,
plane old std C (it just asks for a filename), and mac. Anyway, I
tried to create a FreeGLUT version and it behaves oddly.
I'm calling openfilename from a menu callback, and this probably would
not happen if I wasn't. What happens is the menu callback blocks on
the call to openfilename, and then somehow the menu callback is called
again resulting in a second open file dialog appearing.
The call stack looks something like this (bottom to top):
My Menu Callback
openfile dialog #1
My Menu Callback
openfile dialog #2
Luckily windows is kindly blocking all events to the GLUT window
because the openfile dialog is modal. It appears that an openfile
dialog takes over the message loop of its parent (I guess so the
window can blink and beep if you try to click on it before the dialog
is closed) and something happens that causes it to re-trigger the menu
I did manage to worked around the problem. Instead of calling
openfilename right away, I registered a timer callback to open the
dialog for me 100ms later. Apparently that is enough time for the
menu to get out of the way and not get triggered again.
Not something that needs to be fixed, but something to watch out for
and if anybody ever tries to do the same at least I've documented my
Get latest updates about Open Source Projects, Conferences and News.