FWD » Core Development » User Interface

Please note that MAX-CHARS, RETURN-INSERTED and WORD-WRAP are attributes which need to be implemented as part of this task. They were investigated in #2534. Conversion support and server-side runtime support (setting/getting config values) is already implemented for RETURN-INSERTED. MAX-CHARS and WORD-WRAP are not there yet.

All 3 need client-side implementation as part of the GUI widget implementation. They are GUI-only features.

ca_upd20150510d.zip has passed runtime testing. But there might be more problematic edge cases (like merging lines on backspace/delete, inserting chars on empty lines, etc) which are common to both ChUI and GUI versions. This one can be released, but next phase should keep in mind to check both ChUI and GUI for issues.

Eugenie, can you review the ImageGuiImpl change in 0510d.zip? I wonder if you had a specific reason to return width/height 0 if image is not loaded.

Eugenie, can you review the ImageGuiImpl change in 0510d.zip? I wonder if you had a specific reason to return width/height 0 if image is not loaded.

1. This was there when I have started to work on image support.
2. But I think it is reasonable because what to return if image is not here? We can not imagine the actual image size if we have no image. There are many image options that needs actual size, i.e. stretch to fit, offset, size phrase. Also the button size can depend on the image actual size when image is used to draw button. If the image is not loaded, nothing to draw, what is the alternative for width/height?

Imagine two situations:
1. We have no image and width/height == 0.
2. We have no image and width/height != 0(as possible with your changes).

In both cases there is certainly some kind of issue, either image file is not specified or image can not be loaded for some reasons(missing file for example). These situations needs the user to react. So what is the better signal for trouble?

I have no only right answer here(and have no objection for your change). But I think it is not good to report any features(width/height) for the object that does not exist.

Eugenie Lyzenko wrote:

Imagine two situations:
1. We have no image and width/height == 0.
2. We have no image and width/height != 0(as possible with your changes).

OK, but as I saw with DEFINE IMAGE, if a file is not specified, then a size phrase is required - so I don't think the image can end up with no size. Please test what happens with the image's WIDTH/HEIGHT-CHARS/PIXELS attributes in these cases (image or size phrase).

Please test what happens with the image's WIDTH/HEIGHT-CHARS/PIXELS attributes in these cases (image or size phrase).

If no image file but size specified is not 0, 4GL consider this as "empty" image with given size. "empty" image means the space for image is allocating but no image is drawn.

Eugenie, new question: are you sure the button's DEFAULT attribute needs to be checked in FrameGuiImpl.processDefaultButton? Because 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.

Eugenie, new question: are you sure the button's DEFAULT attribute needs to be checked in FrameGuiImpl.processDefaultButton? Because pressing ENTER in i widget invokes the button's trigger even if the button's DEFAULT attribute is false.

Yes, I was sure it is the correct because according to Progress ABL Reference book page 1531-1532:

...
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.
...

But with your test it works differently, button's DEFAULT attribute is silently ignoring. Looks like the Progress bug or documentation miss. So we have to decide what strategy we will take here.

Looks like the Progress bug or documentation miss. So we have to decide what strategy we will take here.

It doesn't matter what the documentation says. We have found the documentation to be very poor and often incorrect and/or incomplete. This behavior is something we must fix. It will take some additional testcases to confirm the relationship (if any) between the BUTTON:DEFAULT and FRAME DEFAULT-BUTTON option. I've created a new task for this: #2588.

• undo/redo on CTRL-Z
• scrolling via keys/mouse
• selection (added support for CTRL-SHIFT keys, too)
• WORD-WRAP/RETURN-INSERTED/MAX-CHARS attributes
• copy/paste/cut
• navigation: page-up/down, ctrl-left/right, ctrl-home/end
• special keys: ctrl-del (delete to end of line), ctrl-enter (can be used even if RETURN-INSERTED is false)

Code Review 2563b branch (rev 10881)

This is a really good update. I don't have any concerns.

branch 2563b/rev 10882: Fixed javadoc errors. Added mouse-double-click support. Fixed scrolling by mouse and other caret-positioning problems.

No known issues at this point. One more round of testing to confirm that it passes and it's good to go (once Eugenie releases his scroll changes).

branch 2563b/rev 10882 passed testing

rebased branch 2563b, new revision is 10884

Code Review Task Branch 2563b revision 10884

I like the changes, nice improvement.

Hynek's changes will need to be merged. I know you are waiting on Eugenie's to pass and be checked in and then will merge those. My only question is whether you want to go before or after Igor's #2534 changes?

Greg Shah wrote:

... I know you are waiting on Eugenie's to pass and be checked in and then will merge those...

I have already checked in and distributed the 0617b Scrollbar related update. It is required more actions from my side for Constantin to continue working? Are we changing the updates release schema? I just need to know what exactly I have to do to do everything in a right way.

I have already checked in and distributed the 0617b Scrollbar related update.

Right, sorry.

It is required more actions from my side for Constantin to continue working?

No.

Are we changing the updates release schema?

Yes, but you don't have to make any changes right now. We are testing a new process that uses branching instead of update zip files. In the next week or two we will roll it out to the entire company.

Greg Shah wrote:

My only question is whether you want to go before or after Igor's #2534 changes?

I'd like to go after him, it will be easier to do the merge (as it affects the Editor classes).

Rebased task branch 2563b from P2J trunk revision 10888 (new branch revision 10892).

Rebased task branch 2563b from P2J trunk revision 10892 (new branch revision 10896).

Rebased task branch 2563b from P2J trunk revision 10893 (new branch revision 10897).

Rebased task branch 2563b from P2J trunk revision 10894 (new branch revision 10898).

Rebased task branch 2563b from P2J trunk revision 10895 (new branch revision 10899).

There is a compile problem, need to change Igor's Editor.java change in #2534 (rev 10895) to work with the new impl.

Please review task branch 2563b, revision 10903.

Revision 10901 is currently in runtime testing. Revisions 10902/10903 have only GUI changes.

Code Review Task Branch 2563b, Revision 10903

I'm fine with the changes. If it passes testing, please merge/commit to trunk.

Please review task branch 2563b, revision 10907.

I'm running regression testing one more time, to clear some false negatives. I'll merge/commit to trunk once it finishes.

Code Review Task Branch 2563b, Revision 10907

I'm fine with the changes. If it passes testing, please merge/commit to trunk.

Branch 2563b was merged to trunk as revno 10896 then it was archived.