Greetings, 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... regards, Randolf
ce255aba6475c0a7b12f044a8ea700d5184f2b91 Validate whether we propagate WNDPROC as retrieved from 'getDummyWndProc0()' in RegisteredClassFactory 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] modified source
Created attachment 543 [details] modified source
Greetings, 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 other applications. 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. regards, Randolf
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 ***