Bug 899

Summary:	Jogl blocks other applications that try to retrieve window names
Product:	[JogAmp] Jogl	Reporter:	Randolf Schultz <randolf.schultz>
Component:	windows	Assignee:	Sven Gothel <sgothel>
Status:	RESOLVED DUPLICATE
Severity:	major
Priority:	---
Version:	2
Hardware:	pc_x86_64
OS:	windows
Type:	---	SCM Refs:	ce255aba6475c0a7b12f044a8ea700d5184f2b91
Workaround:	---
Attachments:	modified source modified source

Description Randolf Schultz 2013-11-07 16:19:33 CET

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

Comment 1 Sven Gothel 2013-11-10 14:09:58 CET

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]

Comment 2 Randolf Schultz 2013-11-18 15:32:10 CET

Created attachment 542 [details]
modified source

Comment 3 Randolf Schultz 2013-11-18 15:32:41 CET

Created attachment 543 [details]
modified source

Comment 4 Randolf Schultz 2013-11-18 15:40:48 CET

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

Comment 5 Sven Gothel 2013-11-20 19:37:12 CET

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 ***