1. Martin Kaltenböck
  2. PowerBuilder
  3. Thursday, 8 March 2018 08:57 AM UTC

Migrating from PB 12.1 to PB 2017 R2, I found a behaviour change with the setcolumn()-function of the datawindow.

In some freeform datawindows I implemented to skip some columns, when entering or tabbing through the taborder

Example:

[lastname]
[forename]
[secondname] <-- this field is skipped when tabbing through the freeform
[password] <-- this field sometimes is protected by an expression: if (role='admin', 0, 1)
[role]

for skipping the field i use this code in the itemfocuschanged()-event

itemfocuschanged(row, dwo, data):

    choose case dwo.name
    case "forename"
         this.post event ue_setcolumn("password")  // posted to avoid infinite loops (see itemfocuschanged help)
    end choose


ue_setcolumn(as_column):

     this.SetColumn(as_column)


After leaving column [forename] ...


...in PB 12.1:
    Focus is on [password], if not protected
    Focus is on [role], if [password] is protected

    Conclusion: Setcolumn() automatically sets the next editable column in the taborder, if the colum is protected.

...in PB 2017 R2:
    Focus is on [password], if not protected
    Focus is "lost", if [password] is protected <-- this is the error

    Conclusion: Setcolumn() DOES NOT automatically set the next editable column. A getcolumn() after the Setcolumn() returns 0.


The returnvalue of Setcolumn() is always 1.

Has anybody experienced this issue?

Regards, Martin

Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Thursday, 15 March 2018 05:24 AM UTC
  2. PowerBuilder
  3. # 1

Hi Martin,

This is a bug in PB 2017 R2 and we have another customer who reported the same bug (#785, a private one) in our ticketing system. We'll address this bug along with the SetRow issue in the coming release.

We apologize for the inconvenience it caused and appreciate your understanding.

 

Regards,

Ken

Comment
There are no comments made yet.
Martin Kaltenböck Accepted Answer Pending Moderation
  1. Wednesday, 14 March 2018 08:28 AM UTC
  2. PowerBuilder
  3. # 2

Thanks to all the answers!

I worked around this issue by adding two new functions to my framework:

  • of_is_column_editable(as_column)              // returns true if the column is editable
  • of_get_next_editable_column(as_after_column)         // returns the next column after as_after_column that is editable

I use these functions before I do the SetColumn().

BTW, I think the new behaviour is not even a bug, because why should SetColumn() set another column, only because the named column is not editable (as it worked in PB 12).

For this reason I will not open a support case on this.

The only thing that could be improved is, that SetColunn() should return -1 if the Ffcus cannot be set on a column.

Comment
There are no comments made yet.
Govinda Lopez @Appeon Accepted Answer Pending Moderation
  1. Friday, 9 March 2018 17:41 PM UTC
  2. PowerBuilder
  3. # 3

Hi Martin,

 

In a read-only DataWindow, when you click on any column that is not in the current row, the RowFocusChanging and RowFocusChanged events fire, but the current column is not changed -- the current column remains at 0, since no column can have focus. DataWindows are read-only if updates are not allowed, all tab orders are set to 0, or all tab columns are protected.

If, however, focus is on an editable column in an updatable DataWindow (a DataWindow that has one or more editable columns), the row focus events do not fire when you click on a protected column or on a column whose tab order is 0. The focus remains on the current, editable column.

If focus moves off an editable column in an updatable DataWindow, the DataWindow switches to read-only mode. This can happen when the last row in the DataWindow does not have an editable column. In this case, tabbing off the last editable column causes the row focus to move to the row following the row with the last editable column. The DataWindow then remains in read-only mode until focus is given to an editable column.

When you use the ScrollToRow method to change focus, the RowFocusChanging event is triggered before the scroll occurs, and the RowFocusChanged event is triggered after the scroll occurs.

You may find out more about these on page 535 here: https://www.appeon.com/system/files/product-manual/datawindow_reference_0.pdf

As a workaround/solution, I would suggest you to use SetFocus(), SetColumn() and/or SetRow() as needed.

 

 

Regards,

Comment
There are no comments made yet.
Govinda Lopez @Appeon Accepted Answer Pending Moderation
  1. Thursday, 8 March 2018 15:41 PM UTC
  2. PowerBuilder
  3. # 4

Hi Martin,

 

We recommend opening a support ticket and submitting your test case to Appeon Support: https://www.appeon.com/standardsupport/newbug
 
 
Regards,
Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 8 March 2018 15:32 PM UTC
  2. PowerBuilder
  3. # 5

Hi Martin;

  Coincidentally last night, I found the same issue in my OrderEntry example App built from my framework while adding some new code.

Please open a support ticket for this issue.

Regards ... Chris

Comment
There are no comments made yet.
Bjarne Anker Accepted Answer Pending Moderation
  1. Thursday, 8 March 2018 09:13 AM UTC
  2. PowerBuilder
  3. # 6

Hi Martin.

 

We experience some issues which is similar to this, yes.

When we set protected to '1' on a field in a master/detail datawindow using the Linkage service, the master datawindow automatically scrolls to row number 1.

I have reported this as a bug (#826), so hopefully Appeon will find and correct this behavior.

 

Regards,

 

Bjarne Anker

Maritech Systems AS

Norway

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.