Project

General

Profile

Bug #9340

CHOOSE statement does not display widget help string in ChUI

Added by Eugenie Lyzenko over 1 year ago. Updated 5 months ago.

Status:
Internal Test
Priority:
Normal
Assignee:
Tomasz Domin
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
trunk/15548
version_resolved:
reviewer:
Eugenie Lyzenko, Hynek Cihlar
production:
No
env_name:
topics:

fwd_no-help-str.jpg - FWD screen (56.3 KB) Eugenie Lyzenko, 11/14/2024 09:09 PM

4gl_help-str.jpg - 4GL screen (34.7 KB) Eugenie Lyzenko, 11/14/2024 09:09 PM

History

#1 Updated by Eugenie Lyzenko over 1 year ago

The problem is when defining help string for widget including as part of the CHOOSE statement the string is not showing.

The sample:

define var edtpd_tp_doc as character no-undo.
define var edtpd_doc_in as character no-undo.
define var edtpd_exf_mfd_map as character no-undo.
define var edtpd_dtg_name as character no-undo.
define var edtpd_token_list as character no-undo.

edtpd_token_list = "Text".
form
   space  (1)
   edtpd_tp_doc      view-as fill-in size 10 by 1 column-label "Doc Type   " help "Doc Type help string" 
   edtpd_doc_in                                   column-label "Dir   " 
   edtpd_exf_mfd_map view-as fill-in size 20 by 1
   edtpd_dtg_name    view-as fill-in size 15 by 1 column-label "Trans group" 
   edtpd_token_list  view-as fill-in size 15 by 1 column-label "Token list" 
with frame c overlay width 80 title "CHOOSE test" color normal 5 down.

def var i as int.
do i = 1 to 5 with frame c:
   edtpd_tp_doc = string(i).
   edtpd_doc_in = string(i).
   edtpd_exf_mfd_map = string(i).
   edtpd_dtg_name = string(i).
   edtpd_token_list = string(i).
   display edtpd_tp_doc edtpd_doc_in edtpd_exf_mfd_map edtpd_dtg_name edtpd_token_list with frame c.
if i <> 5 then   down  with frame c.
end.

choose row edtpd_tp_doc go-on(F2) with frame c.

FWD screen:

FWD screen

Expected screen:

4GL screen

#2 Updated by Greg Shah over 1 year ago

What trunk revision shows this bug? This seems like a regression.

#4 Updated by Eugenie Lyzenko over 1 year ago

Greg Shah wrote:

What trunk revision shows this bug? This seems like a regression.

I noted from trunk 15548. But I think it was before, I just didn't take this into account. So this is long lived issue. We just had no sample to uncover this.

#5 Updated by Greg Shah over 1 year ago

  • version_reported set to trunk/15548

#6 Updated by Greg Shah over 1 year ago

And this doesn't cause ChUI regression testing to fail? That is surprising.

#7 Updated by Eugenie Lyzenko over 1 year ago

Greg Shah wrote:

And this doesn't cause ChUI regression testing to fail?

Yes. The tests are passing with bug embedded. Only one test GSO 214, step 56 screen check failing or passing.

That is surprising.

May be other 4GL logic masks this overwriting the status line area.

#8 Updated by Tomasz Domin over 1 year ago

  • Status changed from New to WIP
  • Assignee set to Tomasz Domin

#9 Updated by Tomasz Domin over 1 year ago

  • Estimated time set to 5.00
  • Status changed from WIP to Review
  • % Done changed from 0 to 100

Are you sure its a regression ? I've rolled back to revision 15500 and then 15479 it still didnt work properly.

Created task branch 9340a from trunk/15586.
Applied a fix - use HELP attribute from widget for CHOOSE ROW in addition to CHOOSE ROW HELP with a higher priority.
Pushed revision 15587.
Please review.
Will do ChUI regression testing on Monday.

#10 Updated by Tomasz Domin over 1 year ago

  • Estimated time deleted (5.00)

#11 Updated by Greg Shah over 1 year ago

  • reviewer Eugenie Lyzenko, Hynek Cihlar added

#12 Updated by Eugenie Lyzenko over 1 year ago

Tomasz Domin wrote:

Are you sure its a regression ? I've rolled back to revision 15500 and then 15479 it still didnt work properly.

As far as I can see no one told this is a regression.

Created task branch 9340a from trunk/15586.
Applied a fix - use HELP attribute from widget for CHOOSE ROW in addition to CHOOSE ROW HELP with a higher priority.
Pushed revision 15587.
Please review.
Will do ChUI regression testing on Monday.

I have no objection for 15587 change. But ChUI regression testing is required to ensure fix does not introduce new issues.

#13 Updated by Tomasz Domin over 1 year ago

Eugenie Lyzenko wrote:

I have no objection for 15587 change. But ChUI regression testing is required to ensure fix does not introduce new issues.

Thank you.
I am trying too run regression tests but it seems there is a a new regression in trunk the change is based on. Checking it out.

#14 Updated by Tomasz Domin over 1 year ago

There is a regression caused by my change in gso_214. It seems there are cases help string should not be picked up from selected widget. Need to find a condition and working on a fix.

#15 Updated by Tomasz Domin over 1 year ago

  • % Done changed from 100 to 80

#16 Updated by Tomasz Domin over 1 year ago

  • Status changed from Review to WIP

#17 Updated by Tomasz Domin over 1 year ago

Tomasz Domin wrote:

There is a regression caused by my change in gso_214. It seems there are cases help string should not be picked up from selected widget. Need to find a condition and working on a fix.

The issue is related with a fact, that there are several HELP string sources for CHOOSE which are have following priority from the lowest to the highest:
  • database field level help e.g. FIELD doctype AS character LABEL "Doc Type " HELP "database field help"
  • choose row help e.g. choose row tt.edtpd_tp_doc Help "Choose row help" go-on(F2) with frame c.
  • widget level help e.g. form tt.doctype view-as fill-in size 10 by 1 column-label "Doc Type " HELP "widget level help" with frame c

gso_214 fails because choose row help is set to empty string which should override database level help.
The problem I have is how to differentiate Widget Help from database fields, as when having Widget on client side there is only access to config.help which aggregates both.

#18 Updated by Tomasz Domin over 1 year ago

Tomasz Domin wrote:

Tomasz Domin wrote:

There is a regression caused by my change in gso_214. It seems there are cases help string should not be picked up from selected widget. Need to find a condition and working on a fix.

The issue is related with a fact, that there are several HELP string sources for CHOOSE which are have following priority from the lowest to the highest:
  • database field level help e.g. FIELD doctype AS character LABEL "Doc Type " HELP "database field help"
  • choose row help e.g. choose row tt.edtpd_tp_doc Help "Choose row help" go-on(F2) with frame c.
  • widget level help e.g. form tt.doctype view-as fill-in size 10 by 1 column-label "Doc Type " HELP "widget level help" with frame c

gso_214 fails because choose row help is set to empty string which should override database level help.
The problem I have is how to differentiate Widget Help from database fields, as when having Widget on client side there is only access to config.help which aggregates both.

I've implemented a fix in a following way:
  • allowed accessing GenericWidget.isDefaultHelp which stores information if the currently displayed help is the default(overrideable) schema help
  • extended ChooseData to include GenericWidget.isDefaultHelp
  • extended a condition which chooses the right help text

Pushed 9340a/15588.

Regression tests pending. I also need to check if GUI behaves the same way and if not add some guarding code.

#19 Updated by Tomasz Domin over 1 year ago

Tomasz Domin wrote:

Regression tests pending. I also need to check if GUI behaves the same way and if not add some guarding code.

I've checked and GUI have the same HELP selection priorities for CHOOSE as ChUI.
Fixed help selection condition, pushed 9340a/15589 -> Regression testing in progress.
Rebased to trunk/15616 -> Regression testing in progress.

#20 Updated by Tomasz Domin over 1 year ago

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

Tomasz Domin wrote:

Tomasz Domin wrote:

Regression tests pending. I also need to check if GUI behaves the same way and if not add some guarding code.

I've checked and GUI have the same HELP selection priorities for CHOOSE as ChUI.
Fixed help selection condition, pushed 9340a/15589 -> Regression testing in progress.

Regression tests completed successfully, please review an updated 9340a branch.

#21 Updated by Eugenie Lyzenko over 1 year ago

Tomasz Domin wrote:

Tomasz Domin wrote:

Tomasz Domin wrote:

Regression tests pending. I also need to check if GUI behaves the same way and if not add some guarding code.

I've checked and GUI have the same HELP selection priorities for CHOOSE as ChUI.
Fixed help selection condition, pushed 9340a/15589 -> Regression testing in progress.

Regression tests completed successfully, please review an updated 9340a branch.

I have no objections for 15588 and 15589

#22 Updated by Hynek Cihlar over 1 year ago

Code review 9340a. The changes look good, just some minor points.

Just to make the code more beautiful, please move setRowIsDefaultHelp and isRowIsDefaultHelp above readExternal.

GenericWidget.isDefaultHelp should be moved in the section with the default method access rights.

#23 Updated by Tomasz Domin over 1 year ago

  • Status changed from Review to Internal Test

Hynek Cihlar wrote:

Code review 9340a. The changes look good, just some minor points.

Just to make the code more beautiful, please move setRowIsDefaultHelp and isRowIsDefaultHelp above readExternal.

GenericWidget.isDefaultHelp should be moved in the section with the default method access rights.

Thank you, done
Pushed up to revision 15590.

#24 Updated by Hynek Cihlar over 1 year ago

Tomasz Domin wrote:

Pushed up to revision 15590.

Code review, the changes are good.

#25 Updated by Tomasz Domin over 1 year ago

Rebased to trunk/15676
Pushed up 9340a/15680

#26 Updated by Tomasz Domin about 1 year ago

Rebased to trunk/15914
Regression testing passed.
Pushed up to revision 15918.

#27 Updated by Tomasz Domin about 1 year ago

Rebased to trunk/16059
Regression testing passed.
Pushed up to revision 16063.

#28 Updated by Tomasz Domin 5 months ago

Greg
Should I rebase and retest and prepare to merge ?

#29 Updated by Greg Shah 5 months ago

Yes, rebase.

Hynek will control the merge.

#30 Updated by Hynek Cihlar 5 months ago

Tomasz, when do you expect the rebase to be ready?

#31 Updated by Tomasz Domin 5 months ago

Hynek Cihlar wrote:

Tomasz, when do you expect the rebase to be ready?

Rebased to trunk/16425
Added post rebase fix
Pushed up to revision 16430

Will do regression testing today.

#32 Updated by Tomasz Domin 5 months ago

Tomasz Domin wrote:

Will do regression testing today.

I am still doing regression tests, there are more errors than expected, but I need to compare against trunk's baseline.

#33 Updated by Tomasz Domin 5 months ago

Tomasz Domin wrote:

Hynek Cihlar wrote:

Tomasz, when do you expect the rebase to be ready?

Rebased to trunk/16425
Added post rebase fix
Pushed up to revision 16430

Will do regression testing today.

I ran regression tests and they pass the same way as tests for trunk - there are 11/12 tests failing for both.

Also available in: Atom PDF