We Keep Coding

JDialog onTop overlapped by another in a strange way

I am developing a Swing application with custom CSS rendering. As part of the system I use JDialogs as well, but I need to access certain components outside of the dialog (emergency buttons).
For this I chose following method:
all dialogs are non-modal. Those I want to make quasi-modal, will be setAlwaysOnTop.
There is always one quasi modal dialog up. In this case I put another dialog up, below this one, full-screen, semi-permanent.
This "blur" dialog shall cover the whole screen, catch mouse events and forward them to the emergency buttons only. In parallel I opened gaps on it so that the emergency buttons can be seen through the semipermanent surface without any effect.
The blur dialog can never be focused or activated (I have a vetoable listener for this)
Everything works fine, until someting happens and the blur dialog seems to cover my quasi-modal dialog. However, if I move any external application window over it, the quasi-modal dialog remains on the top. Instead of a complicated explanation, see picture un following link: http://lost.lost.hu/javascreen.png
So far I tried to debug repaints, events, everything, and could not find anything that would cause this. Especially the case depicted above challenges me to understand what is going on here.
I have recently updated to Java 1.7, in hope to get rid of this phenomenon, but today it came back.

Capturing events in X11 even after the loss of focus

I am trying to develop an application which responds to multiple digital pens (IRIS Pens) so that if any of the pen writes on paper; I relay the output to a single screen. Thus making a multi-input whiteboard for myself.
In Ubuntu these pens are recognized as mouse and thus can be handled in a similar manner as mouse events are handled.
So now what I plan to do is to handle these events in C/C++ using XLib and pass these events to a Java Swing application using JNI callback. I am able to do this but when the X11 window looses focus no events are transferred to the Swing frame. I also tried to use the root window in X11 but it does not seem to work.
Any help would be really appreciated. Thanking you in advance.

How about maximizing the C/X11 window in front of the Java one, and making it transparent? You should be able to see the Java window while still focusing on the C/X11 one.
Since you are using Ubuntu, you can achieve this using the "Opacity, brightness and saturation" plugin for Compiz. It is in the compiz-plugins-main package, and you can activate it with Compiz Settings Manager (from the compizconfig-settings-manager package). When you activate the plugin, alt+wheel is bound by default to change the transparency of the focused window.

Try reading the mouse directly. I don't remember the exact location, but you should find it in something like '/dev/input/mouseX', where X is the number of your device, ranging from 0 to n-1 devices..
When you read the packet, your application should block until the mouse moves and then your read function will return a raw mouse packet which describes the delta (which is probably more useful then the screen coordinates, in your case) and the mouse button statuses.
The raw packet can be decoded as described here: http://www.computer-engineering.org/ps2mouse/

Create a modal dialog and set it to XmDIALOG_SYSTEM_MODAL (the actual name of the property depends on your toolkit: Motif, Gtk, Qt, ...). Dialogs like this block the whole display and can never loose focus.
The drawback is of course that you can't do anything else while this dialog is on the screen.
This entry in the X11 FAQ might help.

How to refresh the lwuit form?

I am working in a project in which user fills a questionnaire and the answers are then submitted to the server. For simplicity I have just kept two questions per screen and after clicking on the next command the user gets next two questions. I have used lwuit framework in this project.
To reduce the memory requirements I create form, questLabel1, ansCombo1,questLabel2 and ansCombo2 only once. and their properties are set as per the current frame (screen). The problem is if you are in form 2 and you scroll down to the last option and then you click the next button, since you scrolled down the form doesn't displays the upper components even on the next form tried so many thing. creating a new instance of the form may work but I don't want to use that, for obvious memory reasons,
Any other solution?
thanks in advance,

To make it scroll so that component is visible, check Component/Container API javadocs. I've seen at lwuit page these suggest some methods with semantics that fits - scrollComponentToVisible, scrollRectToVisible. "Makes sure the component is visible in the scroll if this container is scrollable..." stuff like that
// above extracted from comment to an answer to make it more visible
// for the case if some reader has similar problem

Have you tried form.revalidate()?. Because this is useful when you modify the container hierarchy and need to redo the layout.
Update: Use requestFocus(); on first component of next form. Its automatically focused on first (Upper) component.

You can use form.refreshTheme() or form.revalidate() for refreshing your form. If you have made updates on any particular container then do the same for container as well.

Listening to all JInternalFrame events - Java

I'm trying to internationalise a Java applet and with that, support scripts which are written from right to left. I want to set up component orientations for all java components added to the view automatically.
My solution so far has to listen to all AWTEvent's using the windows mask:
c.getToolkit().addAWTEventListener(listener, AWTEvent.WINDOW_EVENT_MASK);
...and then setting the c/o on each window added, as well as adding component listeners to set c/o on any components added to the window at a later point.
My issue is that JInternalFrames are not handled by this solution, I want to be able to add another listener for these events, much like I have done for windows. Any ideas?
Or alternatively, are there any better approaches to handling script direction for all components in an applet?

Add a ContainerListener to the JDesktopPane. As a component is added to the desktop you can change its orientation.

Do you have a handle on all those JInternalFrames? If so, try the internal frame listener.
http://java.sun.com/javase/6/docs/api/javax/swing/event/InternalFrameListener.html
It notes that it's the analogue to the AWT WindowListener.

AWTEventListener on the current Toolkit will only give you events coming from the toolkit. Generally events generated by lightweight components will have been caused by mouse or key events.
Asking for all of something in a process is usually a very bad sign. A low-level piece of code is making policy for the whole program. A much better approach is to add listeners near to where you create the component, before it is "realised". This is repeated code, but then you probably already have repeated code. So factor out into a method. Then you have only one place to update, unless you have any cases where it doesn't apply which would have broken the global approach.

Gui - Best way to navigate between windows?

I try to build a gui (Swing) for a simple java application. The application should have a start window like a menu. From there I would like to navigate to several other windows.
My question is what is the best-practice to achieve such a navigation? Should I build several JFrames and switch the visibility of them on/off when navigating OR should I better have one JFrame and add/remove JPanels in this single frame to navigate between the windows?
Thanks.

I recommend
Do not do a MDI application with sub-frames like those found in the old Windows days. They suck as they make the matter confusing.
Do design a tabbed interface. The welcome page/menu will be displayed on a first tab that is always created on the start.
All cool kids do that nowadays:
Visual Studio
Eclipse
Firefox

If each of your windows correspond to different task (possibly nested), you could present your application as a SDI, with on the left a task panel like:
Each of the task would display one JFrame with the associated window.
Other solution: a table of content like this picture on the left side
(note: it actually also displays a task panel in this example on the bottom right)

Multiple JFrames sounds like a better idea to me. Much more OO.

You must find a balance between these goals:
Not too many things in one "window"
The user must quickly be able to find the correct window to do the next step of work
All relevant information must be visible at any time
Eclipse solves this by creating many small editors where each editor shows some specific information and allows to modify it. Editors are then arranged within one OS window in tabs and "views". A view is always completely visible and they can be arranged. Think of a view as a way to cut an existing editor in half (horizontal or vertical) and then being able to replace one of the halves with another editor. Between each half, you have a splitter so you can adjust the sizes.
Arrangements of views are then saved in "perspectives".
This allows every user to create a perspective which contains all the necessary editors at the same time, arrange them as they need it and work effectively.