"Potential" Show stopper for 2017R2 - FIX NEEDED ASAP (sorry )

1
0
-1

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

Question Tags: 

Answers

Govinda Lopez answered "Potential" Show stopper for 2017R2 - FIX NEEDED ASAP (sorry )

1
0
-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,

Rajesh Selvam's picture

Hi Govinda,

We have encountered the same issue. When is the next MR scheduled to be released?

Thanks,

Govinda Lopez's picture

Hi Rajesh,

 

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

 

Regards,

Brian Shelledy's picture

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?

kberghall_15214's picture

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. 

Konstantin Goldobin answered "Potential" Show stopper for 2017R2 - FIX NEEDED ASAP (sorry )

1
0
-1

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

mike@searer.com's picture

https://www.appeon.com/standardsupport/search