Project

General

Profile

Bug #2915

Bug #2677: fix drawing and functional differences between P2J GUI and 4GL GUI

A modal window in Swing GUI client should not be on top of all other OS windows

Added by Hynek Cihlar over 8 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/03/2015
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:

History

#1 Updated by Hynek Cihlar over 8 years ago

A modal window in Swing GUI client should not be on top of all other OS windows. This applies to ALERT-BOX and DIALOG-BOX widget. Most likely this problem will happen to all widgets based on ModalWindow class.

#2 Updated by Hynek Cihlar over 8 years ago

  • Subject changed from A modal window in Web GUI client should not be on top of all other OS windows to A modal window in Swing GUI client should not be on top of all other OS windows

#3 Updated by Hynek Cihlar about 8 years ago

I have not been successful with resolving the issue so far.

The reason the window is always on top is due to javax.swing.JFrame.Type.POPUP set to JFrame.setType(). POPUP is needed in order to make the JFrame not appear on the task bar and there doesn't seem to be any other way for Swing JFrame except using Swing JWindow.

JWindow does not appear on the task bar, but it requires a visible owner window (which is assigned at creation time and can't be changed). If it doesn't get a visible owner, it will never receive focus and hence no keyboard input events. This is a problem because (1) a 4GL program may show an ALERT-BOX for example with no owner window and (2) all 4GL modal windows have the owner set to the default window (which may not be visible).

The most promising path to go seems to be using JWindow with a fake invisible owner window and somehow resolve the keyboard input problem. Either by installing a global key listener (if such a thing exists in AWT/Swing) or force the window to focus.

I will attempt the promising path above and will report back as soon as I have any results.

Any input is welcome.

#4 Updated by Greg Shah about 8 years ago

I think we need to pause work on this. Since it only affects the swing client, it is lower priority for the current customer project.

Before we pause work, please describe a specific recreate that future readers can use to see the issue. The original problem description is a bit vague.

#5 Updated by Hynek Cihlar about 8 years ago

Steps to reproduce the issue.

  1. In Swing GUI client, run a test 4GL program that opens an ALERT-BOX.
  2. Drag a non-P2J window over the ALERT-BOX window.
  3. Notice the ALERT-BOX window is on top of the dragged window, the expected behavior is for the dragged window to cover the ALERT-BOX window.

#6 Updated by Hynek Cihlar about 8 years ago

I have archived task branch 2915a.

#7 Updated by Hynek Cihlar about 8 years ago

Hynek Cihlar wrote:

I have archived task branch 2915a.

Actually I am not sure archiving the branch is the correct step in the process. The branch does not contain any useful changes to be merged to trunk.

#8 Updated by Greg Shah about 8 years ago

Archive it to "dead" instead of the default. The default archive is for things that have already been merged.

#9 Updated by Hynek Cihlar about 8 years ago

Greg Shah wrote:

Archive it to "dead" instead of the default. The default archive is for things that have already been merged.

It is already in p2j_repo/p2j/merged, do you want me to mv it to p2j_repo/p2j/dead?

#10 Updated by Greg Shah about 8 years ago

Yes, please do.

#11 Updated by Hynek Cihlar about 8 years ago

Greg Shah wrote:

Yes, please do.

Done. 2915a was archived to dead.

Also available in: Atom PDF