Project

General

Profile

Bug #2588

test and fix the relationship between BUTTON:DEFAULT and frame's DEFAULT-BUTTON attribute

Added by Greg Shah almost 9 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:

evl_upd20150629a.zip - Default button attribute fix (5.91 KB) Eugenie Lyzenko, 06/29/2015 06:04 PM

evl_upd20150629b.zip - Default imaged button painting approach fix (10.2 KB) Eugenie Lyzenko, 06/29/2015 07:01 PM


Related issues

Related to User Interface - Feature #2446: implement BUTTON and IMAGE GUI widgets (runtime and conversion support) Closed 01/07/2015

History

#1 Updated by Greg Shah almost 9 years ago

It looks like button's DEFAULT attribute does not need to be checked in FrameGuiImpl.processDefaultButton(). Pressing ENTER in i widget invokes the button's trigger even if the button's DEFAULT attribute is false:

DEF BUTTON btn1.
DEF VAR i AS INT.

FORM i btn1 WITH FRAME f1 DEFAULT-BUTTON btn1.

ON 'choose':U OF btn1 IN FRAME f1
DO:
   MESSAGE "choose" btn1:DEFAULT IN FRAME f1.
   RETURN.
END.

UPDATE i btn1 WITH FRAME f1.

This is contrary to the Progress docs (ABL Reference book page 1531-1532) which state:

...
If the DEFAULT attribute is TRUE, the specified button is a default button. To make the specified button the default button for the frame, you must also set the frame’s DEFAULT-BUTTON attribute to the handle of the button.
...
To make the specified button the default button for the frame or dialog box, you must also set the button’s DEFAULT attribute to TRUE.
...

Write the following testcases to check behavior:

1. Does BUTTON:DEFAULT without frame's DEFAULT-BUTTON option still set that button as the default button for the frame?
2. If more than one button has its DEFAULT attribute specified and there is no DEFAULT-BUTTON option, what happens?
3. If more than one button has its DEFAULT attribute specified and there is one DEFAULT-BUTTON option, what happens?
4. If no button has its DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?
5. If one button has its DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?
6. If multiple buttons have their DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?
7. Other cases I've forgotten?

Once the behavior is known, fix our implementation to match the 4GL behavior. Make sure the javadoc/comments explain the real 4GL behavior and not the 4GL documented behavior.

#2 Updated by Eugenie Lyzenko almost 9 years ago

Write the following testcases to check behavior:

1. Does BUTTON:DEFAULT without frame's DEFAULT-BUTTON option still set that button as the default button for the frame?

No default button pressed.

2. If more than one button has its DEFAULT attribute specified and there is no DEFAULT-BUTTON option, what happens?

No default button pressed.

3. If more than one button has its DEFAULT attribute specified and there is one DEFAULT-BUTTON option, what happens?

Only default button specified in frame's DEFAULT-BUTTON attribute get the CHOOSE message.

4. If no button has its DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?

It is not possible to have more than one DEFAULT-BUTTON frame option - syntax error on compilation stage.

5. If one button has its DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?

It is not possible to have more than one DEFAULT-BUTTON frame option - syntax error on compilation stage.

6. If multiple buttons have their DEFAULT attribute specified and there is more than one DEFAULT-BUTTON option for the frame, what happens?

It is not possible to have more than one DEFAULT-BUTTON frame option - syntax error on compilation stage.

7. Other cases I've forgotten?

The DEFAULT-BUTTON points to the button that has no DEFAULT attribute, but other button has the DEFAULT attribute set to true(but not specified in frame's DEFAULT-BUTTON option as default one)

Only button specified in frame's DEFAULT-BUTTON option gets the CHOOSE message

Once the behavior is known, fix our implementation to match the 4GL behavior. Make sure the javadoc/comments explain the real 4GL behavior and not the 4GL documented behavior.

The conclusion is only DEFAULT-BUTTON frame option has meaning when defining the button to be default for the given frame. So we have to just ignore BUTTON:DEFAULT attribute in message processing of the FrameGuiImpl class.

#3 Updated by Constantin Asofiei almost 9 years ago

Eugenie Lyzenko wrote:

The conclusion is only DEFAULT-BUTTON frame option has meaning when defining the button to be default for the given frame. So we have to just ignore BUTTON:DEFAULT attribute in message processing of the FrameGuiImpl class.

This should be already covered in branch 2563b FrameGuiImpl.processDefaultButton - please double check this branch with your tests.

#4 Updated by Eugenie Lyzenko almost 9 years ago

This should be already covered in branch 2563b FrameGuiImpl.processDefaultButton - please double check this branch with your tests.

Do you mean the fix same as the one included in the update attached already completed and preparing to be released?

#5 Updated by Constantin Asofiei almost 9 years ago

Eugenie Lyzenko wrote:

This should be already covered in branch 2563b FrameGuiImpl.processDefaultButton - please double check this branch with your tests.

Do you mean the fix same as the one included in the update attached already completed and preparing to be released?

Yes, it's the same fix. But I think it's OK to create a distinct revision for this, as the issue is specific enough. I needed this change too to test the EDITOR's RETURN-INSERTED attribute, which didn't work without an attached button.

You can go ahead and release it (no testing required, only GUI code is changed), I'll just merge my changes with yours.

#6 Updated by Eugenie Lyzenko almost 9 years ago

The fix has been committed in bzr as 10890. Will be distributed shortly.

#7 Updated by Eugenie Lyzenko almost 9 years ago

There is one more place to modify regarding this bug. The GUI button does not display image for default button. So the logic to check this condition should be changed to test only frame's DEFAULT-BUTTON attribute only. The button DEFAULT attribute is silently ignoring in this case too.

Please review the change. I can release it because as before no testing is required for GUI code.

#8 Updated by Constantin Asofiei almost 9 years ago

Please review the change. I can release it because as before no testing is required for GUI code.

I'm OK with the change, go ahead and release it.

#9 Updated by Eugenie Lyzenko almost 9 years ago

Constantin Asofiei wrote:

I'm OK with the change, go ahead and release it.

Committed in bzr as 10891.

#10 Updated by Greg Shah almost 9 years ago

  • Status changed from New to Closed

#11 Updated by Greg Shah over 7 years ago

  • Target version changed from Milestone 12 to GUI Support for a Complex ADM2 App

Also available in: Atom PDF