Bug #2588
test and fix the relationship between BUTTON:DEFAULT and frame's DEFAULT-BUTTON attribute
0%
Related issues
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'sDEFAULT-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 noDEFAULT-BUTTON
option, what happens?
No default button pressed.
3. If more than one button has its
DEFAULT
attribute specified and there is oneDEFAULT-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 oneDEFAULT-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 oneDEFAULT-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 oneDEFAULT-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 theFrameGuiImpl
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
- File evl_upd20150629a.zip added
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
- File evl_upd20150629b.zip added
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