Project

General

Profile

Bug #10521

« Previous | Next »

RADIO-SET Rendering in ChUI Issues

Added by Vladimir Tsichevski 11 months ago. Updated 7 months ago.

Status:
Test
Priority:
Normal
Assignee:
Razvan-Nicolae Chichirau
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
Hynek Cihlar
production:
No
env_name:
topics:

10521-FWD-2.png (793 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-FWD-3.png (798 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-FWD-4.png (774 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-OE-1.png (969 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-OE-2.png (943 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-OE-3.png (929 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

10521-FWD-1.png (800 Bytes) Vladimir Tsichevski, 09/04/2025 10:09 AM

Related issues

Related to User Interface - Bug #10512: REGRESSION: In ChUI, all RADIO-SET items are positioned at the same location Closed

History

#1 Updated by Vladimir Tsichevski 11 months ago

  • Related to Bug #10512: REGRESSION: In ChUI, all RADIO-SET items are positioned at the same location added

#2 Updated by Vladimir Tsichevski 11 months ago

Scenario

DEFINE VARIABLE x AS INTEGER
   INITIAL 0
   VIEW-AS RADIO-SET 
   HORIZONTAL
   RADIO-BUTTONS
   "EN", 0,
   "OF", 1.

DEFINE VARIABLE y AS INTEGER
   INITIAL 0
   VIEW-AS RADIO-SET 
   VERTICAL
   RADIO-BUTTONS
   "EN", 0,
   "OF", 1.

DEFINE FRAME f x SKIP y WITH SIDE-LABELS.
ENABLE ALL WITH FRAME f.

WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW.

In this example, two RADIO-SET widgets are defined: one configured horizontally and the other vertically. Execute this example in CHARACTER (ChUI) mode.

In OpenEdge (OE), the display appears as expected:

Issue 1: In FWD, the RADIO-SET widgets are rendered one character wider than in OE:

Issue 2: use the Left key to move the selection in the horizontal RADIO-SET to the OF item.

In FWD, the caret is highlighted to the right of the selected OF item:

In OE, this highlighting does not occur:

A similar problem is present with the vertical RADIO-SET in FWD:

When the user shifts focus from the vertical RADIO-SET back to the horizontal one using the TAB key, the highlighting does not disappear:

#3 Updated by Razvan-Nicolae Chichirau 7 months ago

  • Assignee set to Razvan-Nicolae Chichirau
  • Status changed from New to WIP

I'll take a look at this.

#4 Updated by Razvan-Nicolae Chichirau 7 months ago

  • % Done changed from 0 to 100
  • Status changed from WIP to Review

Issue 1: In FWD, the RADIO-SET widgets are rendered one character wider than in OE:

The culprit is when calculating the width size in RadioSet.refreshItemsImpl():

final double nextButtonXOffset = buttonWidth + hExtraDist;
final double buttonHeight = button.height();
size += isHorizontal ? nextButtonXOffset : buttonHeight;

For each button we add the extra distance between the radio set buttons, even for the last button which doesn't make sense.

Issue 2: use the Left key to move the selection in the horizontal RADIO-SET to the OF item.

The bug is happening only when we are focused on a radio-set button that is not selected. The culprit is in ThinClient.positionCursor():

else if (comp instanceof RadioSet)
{
   RadioButton<OutputManager<?>> selected = ((RadioSet) comp).getSelected();
   if (selected != null)
   {
      selected.drawCaret();
   }
}

4GL ChUI draws the caret on the focused button, not the selected one.

Hynek: Please review 10521a/rev. 16317.

#5 Updated by Hynek Cihlar 7 months ago

  • Status changed from Review to Internal Test

Razvan-Nicolae Chichirau wrote:

Hynek: Please review 10521a/rev. 16317.

Code review. The changes look good.

Please run the ChUI regression tests. Also please do manual ChUI regression testing as AFAIK Harness does not check highlights.

#6 Updated by Razvan-Nicolae Chichirau 7 months ago

Testing that passed successfully:
  • Smoke-tested ChUI and GUI for 2 customer apps + Hotel
  • ChUI regression tests
  • Isolated cases, such as #10521-2

If this is enough, 10521a should be merged.

#7 Updated by Hynek Cihlar 7 months ago

  • Status changed from Internal Test to Merge Pending

Please merge 10521a to trunk.

#8 Updated by Razvan-Nicolae Chichirau 7 months ago

  • Status changed from Merge Pending to Test

Branch 10521a was merged into trunk as rev. 16326 and archived.

Also available in: Atom PDF