Properties dialog focus [message #49491] |
Tue, 13 July 2004 05:53  |
Eclipse User |
|
|
|
For some property that require popup dialog, like the panel border one,
fonts, colors, the focus behaviour is erratic.
When I open the dialog by editing the propery, a few times it doesn't
receive focus.
When I close it, many times Eclipse main window stops being the active
system window.
This is a little annoying, and think it must have an easy solution.
|
|
|
|
|
Re: Properties dialog focus [message #50239 is a reply to message #49983] |
Wed, 14 July 2004 10:00  |
Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
The problem is we still can't get the "handle" that Java uses for the
frame to use for JNI. Java doesn't expose it.
As for non-user code, we actually do that. Many of the standard number
and string editors run in the IDE. Those that run in the remote VM are
ones that are supplied through BeanInfo and ones that require access to
the runtime environment. For example, Color and Font run on the remote
VM because the colors and font are very VM specific. If we ran them in
the IDE we could get a different set of colors and fonts. Those that are
supplied be BeanInfo need to run in the remote VM because they were
written to the BeanInfo spec, which expects the property editors
supplied by BeanInfo to run in the same VM as the part being edited.
--
Thanks, Rich Kulp
|
|
|
Re: Properties dialog focus [message #595060 is a reply to message #49491] |
Tue, 13 July 2004 10:08  |
Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
Actually there isn't anything we can do. This is a "feature" of Windows.
You see those dialogs are actually running in a separate process. This
is because we run all of the user code (including property editors) in a
separate process. We use a separate process for several reasons. The
primary one is that we don't want to run user code in the same process
as Eclipse. We wouldn't be able to dynamically modify classes without
some real fancy classloader footwork. Also it allows the user code to be
developed for a different vm or locale than the one running VE.
Because it is a separate process, Windows doesn't always allow a frame
from a process different than the one that is active take the focus and
become active. It is kind of erratic, but that is Windows. It will flash
the new frame in the Windows task bar to let you know it is trying to
become active. The same happens in reverse, that is why the editor
doesn't always get focus back.
There is a C API that allows forcing to come to the front, but can't use
it with Java.
--
Thanks, Rich Kulp
|
|
|
Re: Properties dialog focus [message #595140 is a reply to message #49699] |
Wed, 14 July 2004 03:37  |
Eclipse User |
|
|
|
Thank Rich for the answer.
And couldn't that API be called from JNI?
For standard Swing Widgets, that aren't user code, couldn't be launched in
the same JVM, and leave the old behaviour for user code?
Rich Kulp wrote:
> There is a C API that allows forcing to come to the front, but can't use
> it with Java.
|
|
|
Re: Properties dialog focus [message #595231 is a reply to message #49983] |
Wed, 14 July 2004 10:00  |
Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
The problem is we still can't get the "handle" that Java uses for the
frame to use for JNI. Java doesn't expose it.
As for non-user code, we actually do that. Many of the standard number
and string editors run in the IDE. Those that run in the remote VM are
ones that are supplied through BeanInfo and ones that require access to
the runtime environment. For example, Color and Font run on the remote
VM because the colors and font are very VM specific. If we ran them in
the IDE we could get a different set of colors and fonts. Those that are
supplied be BeanInfo need to run in the remote VM because they were
written to the BeanInfo spec, which expects the property editors
supplied by BeanInfo to run in the same VM as the part being edited.
--
Thanks, Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.03404 seconds