our application (using Jogl in a GLJPanel) blocks third party software that
use the EnumWindows()/GetWindowText() Win32 functions to discover/retrieve
window title names.
A potential candidate are the Jogl dummy windows, which are (by error) created
with no wndproc! Well, atleast my Eclipse says, that in the method
public RegisteredClassFactory(String classBaseName, long wndProc)
the wndProc parameter is always 0. However, I see no reason for this,
as the JNI call to getDummyWndProc0 and its C-implementation seem to be
correct. But the 0 would explain why the GetWindowText() hangs, as the
window class associated with the dummy window would then have no WindowProc
that processes events...
Validate whether we propagate WNDPROC as retrieved from 'getDummyWndProc0()' in
Result: Yes we do.
Note: The RegisteredClassFactory mechanism is used for NEWT Windows as well.
GDI.initSingleton() dummyWindowClassFactory RegisteredClassFactory[moduleHandle 0x13f3e0000, _dummyWindow_clazz, wndProc 0x6c101de6, shared[refCount 0, class null]]
GDI.CreateDummyWindow() dummyWindowClassFactory RegisteredClassFactory[moduleHandle 0x13f3e0000, _dummyWindow_clazz, wndProc 0x6c101de6, shared[refCount 1, class RegisteredClass[handle 0x13f3e0000, _dummyWindow_clazz0]]]
GDI.CreateDummyWindow() dummyWindowClass RegisteredClass[handle 0x13f3e0000, _dummyWindow_clazz0]
Created attachment 542 [details]
Created attachment 543 [details]
further analysis revealed, that the wndProc is indeed transported
correctly through JNI; I was fooled by Eclipse.
I fixed the issue by changing the dummy window creation process
to occur each in its own thread that then falls into a message
processing loop for this window.
The dummy window destruction also needed to change to not use
DestroyWindow() but to send a WM_CLOSE message instead.
See the attached files.
With these changes in place, our application no longer blocks
The thread handling is a bit clumsy; for instance, currently
the application will hang if the CreateWindowEx() fails for some
reason. Nevertheless, I would be grateful, if these changes would
find their way into the trunk.
IMHO this bug should have been reopened .. author chose to create a duplicate we use to work on now.
*** This bug has been marked as a duplicate of bug 907 ***