Bug #2788: alert-box close button (in the titlebar) should be disabled - User Interface - Golden Code Redmine

Bug #2788

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

alert-box close button (in the titlebar) should be disabled

Added by Greg Shah over 8 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Hynek Cihlar

Target version:

FWD - Cleanup and Stabilization for GUI

Start date:

Due date:

% Done:

100%

billable:

vendor_id:

GCD

case_num:

History

#1 Updated by Greg Shah over 8 years ago

Although it is drawn as disabled, in P2J the button is active. The user can dismiss the alert-box using the close button in P2J. This is NOT possible in the 4GL. The close button does not respond to mouse events on windev01.

#2 Updated by Greg Shah about 8 years ago

Target version changed from Milestone 12 to Milestone 16

#3 Updated by Hynek Cihlar about 8 years ago

Task branch 2788a revision 11006 fixes the problem mentioned in note 1. It also fixes window caption button not to change press state when not enabled, and fixes ALERT-BOX close button to properly close the box (when enabled) with the correct result.

Please review.

#4 Updated by Greg Shah about 8 years ago

Code Review Task Branch 2788a Revision 11006

1. Should AlertBoxGuiImpl.init() call setClickHandler() before setCaptionButtonEnabled()? Perhaps it is already safe because it is in the init() processing. It seems like a (admittedly rare) possible race condition. But if an event processes in between the two, then there would be the chance to process the default path for CLOSE instead of the overridden version.

2. All 3 programs need a history entry.

#5 Updated by Hynek Cihlar about 8 years ago

Greg Shah wrote:

Code Review Task Branch 2788a Revision 11006

1. Should AlertBoxGuiImpl.init() call setClickHandler() before setCaptionButtonEnabled()? Perhaps it is already safe because it is in the init() processing. It seems like a (admittedly rare) possible race condition. But if an event processes in between the two, then there would be the chance to process the default path for CLOSE instead of the overridden version.

Actually there is no race condition here. All user input is handled through event queues, so the eventual mouse click clicked exactly between setCaptionButtonEnabled() and setClickHandler() would get queued and processed after setClickHandler() is already called.

2. All 3 programs need a history entry.

Sorry, added in 11007.

#6 Updated by Greg Shah about 8 years ago

Please merge these changes into 1811u.

BTW, 1811u is due for a rebase. I think that won't affect your merge, but if it does, then wait for the rebase before you merge.

I'll close this task once it is merged to 1811u.

#7 Updated by Hynek Cihlar about 8 years ago

Greg Shah wrote:

Please merge these changes into 1811u.

BTW, 1811u is due for a rebase. I think that won't affect your merge, but if it does, then wait for the rebase before you merge.

I'll close this task once it is merged to 1811u.

Yes, the changes should be safe, I am gonna merge to 1811u now.