FWD » Core Development » User Interface

1. Search is performed using only the first character in the first column.
2. The full set of charaters the browse reacts to is to be investigated, but most likely it matches the set of printable characters.
3. Browse looks for the next row (in browse display order) which starts with the given character. If not found, search is continued from the top. If not found from the top and the current row matches the key, search returns to the current row (it is considered as the found row and scrolling is performed accordingly).
4. If found row is before the current top row in the view (according to the current size of the result set, deleted rows are not taken in consideration) then browse is scrolled so the found row becomes the top row. Otherwise browse is scrolled so the found row becomes the bottom row.
5. If target row is in the view after the current row - no scrolling is performed, target row is selected.
6. If there is no found row and the current row is in the view or out of the view ABOVE it then the browse is scrolled up at maximum by (DOWN - 1) till the current row becomes the bottom row or until we scrolled to the top or to the (DOWN - 1)th row above (according to the current size of the result set, deleted rows are not taken in consideration). Current row remains the same.
7. If there is no found row and the current row is BELOW the view then nothing happens.

This task must also implement ALLOW-COLUMN-SEARCHING and the START-SEARCH and END-SEARCH events. See #2564-276 (and note 277) for details.

The app definitely does set ALLOW-COLUMN-SEARCHING = TRUE in multiple places.

I don't see any string literals that match start-search or end-search, which suggests that the app may not implement the events processing code. But the use of the attribute still probably changes behavior of the browse.

I'm imclined to just implement all of it now. I do think it is important to get the feature right for the case where the triggers are missing for start-search or end-search. It is one thing to postpone work on quirks but these features seem pretty core.

should I implement SORT-ASCENDING and SORT-NUMBER attributes for displaying sorting direction and sort-level number?

Yes, please do.

Note that the pressed column header is some kind of rectangle with top-left shadow. We don't have this P2J so I've replaced it with the classical rectangle which is the closest choice.

Note that the pressed column header is some kind of rectangle with top-left shadow. We don't have this P2J so I've replaced it with the classical rectangle which is the closest choice.

Are you manually drawing the highlights using lines?

We had this same requirement for menus, if I recall correctly. Probably, the right thing to do is to implement the primitive drawing function in both drivers.

Do you know if there are any other elements which should be drawn using not-raised 3D rect?

Do you know if there are any other elements which should be drawn using not-raised 3D rect?

Vadim/Hynek/Eugenie: Can any of you identify cases where this "inverted" highlight is simulated using manual drawing of the highlight. I seem to recall that we may do it for buttons and for menus, but I don't recall for sure.

Greg Shah wrote:

Do you know if there are any other elements which should be drawn using not-raised 3D rect?

Vadim/Hynek/Eugenie: Can any of you identify cases where this "inverted" highlight is simulated using manual drawing of the highlight. I seem to recall that we may do it for buttons and for menus, but I don't recall for sure.

From my knowledge/work:
Push buttons, Fill-in and combo-box entry, Editor, Slider buttons, Toggle-box. I think everywhere when we need "inverted" highlight we need to implement this simulation because draw3DRect() API does not exactly match the requirement to simulate pure Windows GUI parts for classic theme.

Eugenie Lyzenko wrote:

Greg Shah wrote:

Do you know if there are any other elements which should be drawn using not-raised 3D rect?

Vadim/Hynek/Eugenie: Can any of you identify cases where this "inverted" highlight is simulated using manual drawing of the highlight. I seem to recall that we may do it for buttons and for menus, but I don't recall for sure.

From my knowledge/work:
Push buttons, Fill-in and combo-box entry, Editor, Slider buttons, Toggle-box. I think everywhere when we need "inverted" highlight we need to implement this simulation because draw3DRect() API does not exactly match the requirement to simulate pure Windows GUI parts for classic theme.

I would also confirm that menu widgets need "inverted" highlight.

Although these cases look similar I haven't seen another case with the inner top-left shadow with width 1px less than the actual width. I don't think we can and should provide an unified solution.

Although these cases look similar I haven't seen another case with the inner top-left shadow with width 1px less than the actual width. I don't think we can and should provide an unified solution.

I understand that you can use a manual drawing approach (rectangle and lines) to match the pixel by pixel result. Perhaps this is the right thing to do. But part of the problem here is that for 3D rectangle drawing, the shading colors are calculated automatically based on the rectangle color. Today this is done by the driver (actually Swing does it in the case of the Swing client, but for the web client we have our own calculation in the driver).

I suspect that all of the similar code where we manually draw will have the wrong shadow colors when we allow the customer to override colors and/or when we allow switchable themes (#2676).

In this case the shading color is constant. BTW, I didn't notice that it is also true for raised 3D headers, so I should manually draw this shadow for both states of a column header.

Created task branch 2959a from trunk revision 11084.

At this point the sort mechanics from the note 4 is implemented for the most part - it still needs some pixel-perfect drawing work to be done. Search mechanics from the same note was investigated but implementation hasn't started.

Rebased task branch 2959a from P2J trunk revision 11095.

Rebased task branch 2959a from P2J trunk revision 11128.

Code Review Task Branch 2929a Revision 11131

The changes look good.

It seems like most everything we need for #3228 is there. It is not clear what needs to be done to stabilize this. Other than rebasing and adding history entries/javadoc, what else is needed for this?

Ovidiu, can you take a look at searchpath in directory.xml, too? From what I see, this is OS-dependent, too...
Meant for #3225

Rebased task branch 2959a from P2J trunk revision 11140.

It is not clear what needs to be done to stabilize this. Other than rebasing and adding history entries/javadoc, what else is needed for this?

There are visual issues in drawing sort arrows and numbers in columns header. We need to check if they are displayed in POC. So far I'm planning to add javadoc to this branch and merge to 3209e.

When will you be able to merge into 3209e? I need it to convert the POC code, which I'm trying to get done as early in the weekend as possible so that I can start testing. We need to get some idea of the issues that have to be resolved.

We need to check if they are displayed in POC.

Understood. Are these related to the SORT-ASCENDING and SORT-NUMBER attributes? If so then we are OK because those attributes are not used in the POC code.

When will you be able to merge into 3209e?

In an hour. Sorry for delay, I didn't think it is urgent.

Understood. Are these related to the SORT-ASCENDING and SORT-NUMBER attributes?

Yes. AFAIK they cannot be cannot be triggered by some in-browse actions, and have to be explicitly set. That is good. However I would like to take a look how sorting actually works in POC, who knows what may emerge.

Branch 2959a was merged into 3209e and archived. I'll add missing svg files later.

Please note I'll be unavailable for the rest of the day.

1. Horizontally symbol "1" is positioned as it is a fixed-width font (while it doesn't look so visually).
2. Vertically numbers are positioned exactly in the middle, unlike column labels which are positioned in the middle according to the text metrics (more space on top).

What I'm saying is that positioning sort numbers according to text metrics is possible only with some hard-coded offsets: vertical and, for "1": horizontal.
I suspect that 4GL just uses bitmaps for this numbers (I haven't yet tried to check resources in 4GL files to prove that) and I suggest to go this way too. What do you think?

I suspect that 4GL just uses bitmaps for this numbers (I haven't yet tried to check resources in 4GL files to prove that) and I suggest to go this way too. What do you think?

I'm fine with this approach.

Created task branch 2959b from trunk revision 11143.

These rules describe how the row found by key is positioned in the view depending on 1. how the current row is positioned relatively to the view. 2. how the found row is positioned relatively to the view and to the current row.

• first page - current/found row is on the first page of the result set;
• cycle - result wasn't found after the current row, search was continued from the top;
• bottom - the view is scrolled so the found row becomes the bottom row;
• top - the view is scrolled so the found row becomes the top row;
• page up - current view is scrolled up by (DOWN - 1);
• option 1 — current row becomes top row, found row is highlighted;
• option 2 — scroll to first row in the result set, highlight found row;
• option 3 — scroll to first row in the result set, highlight current;
• X - this combination can't happen.
  Note that unless "first page" is explicitly specified, the current/found row is NOT on the first page of the result set.

Nice work!

Does "X" mean "this combination can't happen"?

How much time is needed to create the implementation matching these rules?

Does "X" mean "this combination can't happen"?

Yes. I've updated the legend.

How much time is needed to create the implementation matching these rules?

A couple of days.

Stanislav, a question: if BROWSE is in focus and a printable key is pressed, if there is an ANYWHERE trigger (or another trigger which can catch it), will the trigger be invoked? If is invoked, how will search-by-key behave if the trigger has RETURN NO-APPLY (or not)?

Stanislav, a question: if BROWSE is in focus and a printable key is pressed, if there is an ANYWHERE trigger (or another trigger which can catch it), will the trigger be invoked?

Yes.

If is invoked, how will search-by-key behave if the trigger has RETURN NO-APPLY (or not)?

Search is not performed if there was a fired trigger.

Rebased task branch 2959b from P2J trunk revision 11146.

Rebased task branch 2959b from P2J trunk revision 11147.

Please review task branch 2959b rev 11155.

Stanislav Lomany wrote:

Please review task branch 2959b rev 11155.

Stanislav, the changes in 2959b look OK to me.

From what I see, search by key works only for the first char in the browse cell, correct?

From what I see, search by key works only for the first char in the browse cell, correct?

Correct.

Rebased task branch 2959b from P2J trunk revision 11148.

Passed regression testing.
Rebased task branch 2959b from P2J trunk revision 11149.
Should I check in?

Stanislav Lomany wrote:

Passed regression testing.
Rebased task branch 2959b from P2J trunk revision 11149.
Should I check in?

Yes, go ahead.

2959b has been merged into the trunk as bzr revision 11150.

Are there items implemented in 2959a and 2959b which need to be updated in our gap analysis marking?

Are there items implemented in 2959a and 2959b which need to be updated in our gap analysis marking?

If you mean the list #3275-1 then no.

No, I'm referencing the changes made in this task. For example, the existing marking for ALLOW-COLUMN-SORTING, SORT-ASCENDING, SORT-NUMBER... are probably out of date now. They are all working fully now in trunk, right?

Please make the updates in 1514a (@rules/gaps/expressions.rules) that match the state of the trunk in regard to 2959a and 2959b. We are trying to get a new drop of 1514a released, so doing this quickly would be appreciated.

No, I'm referencing the changes made in this task. For example, the existing marking for ALLOW-COLUMN-SORTING, SORT-ASCENDING, SORT-NUMBER... are probably out of date now. They are all working fully now in trunk, right?

Yes. I've made changes to rules/gaps/expressions.rules in 1514a.

For dynamic browse one can set validation expression using VALIDATE-EXPRESSION and VALIDATE-MESSAGE attributes. However in P2J it is implemented incorrectly: it sets expression/message globally rather than buffer-wide. Testcase:

FIND FIRST book.
DEF BUFFER book2 FOR book.
DEF VAR h AS HANDLE.

h = BUFFER book2:BUFFER-FIELD("book-id").
h:VALIDATE-EXPRESSION = "book-id > 55".
h = BUFFER book:BUFFER-FIELD("book-id").
MESSAGE h:VALIDATE-EXPRESSION. /* should NOT be "book-id > 55" */