1. Georgios Papageorgiou
  2. PowerBuilder
  3. Tuesday, 13 February 2018 16:50 PM UTC

Hi PowerSphere,

We discovered a very serious bug in the SetRow() functionality.

Click on a computed field in another row than current (in the Clicked event there is a SetRow(row)  ) - move the mouse away of the field( computed you just clicked on) - and the value of the previous row is shown in the current rows "input field"

Seems you can bypass it with a Post SetRow() - but whar will this break - and how many places do you have to do this (if possible)

 

We are making a bug example to post to support - but the are having Chinese Holiday and will first be back later this month. (Hope the development team will be working :) )

Bug report #768 (edited)

Seems we have to revert to 2017 - leaving all the GIT fun behind - :( :( :(

 

Regards

Georgios

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

Hi,

The fix is scheduled for March 31, 2018. After this date, please download the updated version of PowerBuilder 2017 R2 from the Appeon User Center: https://www.appeon.com/user/center/index#download

Regards... Ken

 

Comment
There are no comments made yet.
Govinda Lopez @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 13 February 2018 18:00 PM UTC
  2. PowerBuilder
  3. # 1

Hi Georgios,

 

We are very sorry for this issue. 

It is the same issue as that is reported in bug ID #744 and we’ll address it with priority in our next MR 

 

Regards,

Comment
  1. Govinda Lopez @Appeon
  2. Friday, 16 February 2018 17:07 PM UTC
Hi Rajesh,



 



We don't have a release date yet. Once we do, we will announce it.



 



Regards,

  1. Helpful
  1. Brian Shelledy
  2. Friday, 16 February 2018 17:39 PM UTC
We are also experiencing something related to this issue, and now we are having to roll back our production environment to R1 because you guys don't have a date for this fix, are all on vacation for Chinese new year, and the tickets related to this breaking change effecting thousands of lines of existing code is still marked P3.  Why aren't these tickets marked P2 at least, or P1?

  1. Helpful
  1. Kim Berghall
  2. Monday, 19 February 2018 20:10 PM UTC
Same issue, we have reported and provided sample window/dw how to reproduce. It seems to be related to clicked event with setrow(). Very serious core PB functionality capability. This should be highest priority at Appeon. We are forced to roll back to R1. This bug is confirmed to have been introduced in R2. There is also another smaller bug that seems to be related where values in some fields display based on the value where the cursor was before. I have reported that too with sample code. We are very frustrated right now, should we try to work around the bug in hundreds of places or go back to R1. We already waited on R2 because of the PDF fix (which works great), so if we go back then we have to go back to the old distill PDF, which is okay. Another question: Is there a formal list of things that got fixed in R2? The bulletin only list things that got broken. 

  1. Helpful
There are no comments made yet.
Konstantin Goldobin Accepted Answer Pending Moderation
  1. Sunday, 18 February 2018 09:45 AM UTC
  2. PowerBuilder
  3. # 2

This is really scary... What kind of QA does PB go through if bugs in basic functionality go unnoticed? BTW, does anyone know where I can see the list of open issues?

Best regards,
Konstantin

Comment
  1. mike S
  2. Monday, 19 February 2018 14:26 PM UTC
  1. Helpful
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.