Taking the user for a ride by sounding clever - we all do it

Posted by Simon L. Prinsloo on 23-Mar-2016 05:17

I've just seen this new KB entry:

ABL:ON LEAVE FAILS FOR LAST FIELD IN FRAME WHEN USING EDITING

Truth is that is also happens when you:

DISPLAY...

ENABLE...

WAIT-FOR GO OF FRAME....

The LEAVE event used to fire, since v. 7, for each field when you leave it and, in the event of GO OF FRAME, also for the current field, before the GO event.

The KB says this:

The fix for this issue is expected to be in the upcoming release 11.6.2.

But in "Clarifying information" it states the tale we used to hear:

This behavior has been present since at least 9.1E04.

There may be applications that rely on the current behavior and firing a LEAVE event where one didn't fire before could break them.

Well, yes. Most of us working with the language for more than a decade probably know that bug well.  

I've worked on many systems since 1996 (v.7). Particular ones that stands out are one in 1997 (v.8.0 GUI), 1998 (8.2 ChUI)  and the biggest one from 1999 (v 9.0 ChUI) to 2010. (To mention just two of many I know.)

  • All use variations of the same framework, based on code dating back as far as v. 7, which relies on the fact that the leave trigger will fire when you LEAVE the field or when the frame GO.
  • All three are still in production today.
  • All three are running on modern versions of OpenEdge.
  • At least the last one one is still growing rapidly.
  • All three have thousands of screens that fail to properly validate the field in focus, unless the validation was repeated in the GO OF FRAME event.

And I am but one little peanut in the packet..... 

We had live with this bug since it was introduced. We had to accept for years that thousands of old programs are now malfunctioning. Thousands of us regularly jump through hoops to get that last field right. But we could not be helped because somewhere someone have might have had the following use case:

"I want to write code that must never run, so I put it in the leave of my last field, because there is a bug that will cause it not to fire and Progress will not fix the bug."

Why on earth will anybody have a LEAVE trigger and then rely on it to NOT fire? I for one is too lazy to write code for the sole purpose of it NOT running.

To be honest, I see only one way that "There ARE MANY actually existing applications relying on the DOCUMENTED behaviour..." gets trumped by "There MAY BE [buggy] applications  relying on the current [not as documented and implemented in v. 7] behaviour."

I am a programmer myself. That is the sort of crooked argument we use when we either do not know how to fix something or simply do not want to do it. Users are insulted by such word games.

On the other hand, users appreciate the truth, so why don't we rather say:

  1. This is a bug.
  2. It been there for over 10 years, because it never reached the top of the priority stack.
  3. Most critical cases suffering from it would have found workarounds in the decade since, so its priority keeps dropping.
  4. It will never be fixed. 

Think about it. The user sigh, moan, groan, but accept it. Also updating it to read as follows is much nicer than admitting "After a decade of spinning stories on this, we've ran out of runway and will now fix it."

[UPDATE]

  1. This is a bug.
  2. It been there for over 10 years, because it never reached the top of the priority stack.
  3. Most critical cases suffering from it would have found workarounds in the decade since, so its priority keeps dropping.
  4. BUT WE ROCK. We worked the backlog down so much that it IS NOW at the top of the stack!
  5. The fix for this issue is expected to be in the upcoming release 11.6.2. (Unless something more important comes in.)

All Replies

Posted by Matt Gilarde on 23-Mar-2016 05:50

Defect PSC00345501 was submitted on February 25, 2016. The fix was checked in on March 7, 2016. The bug has existed for a long time but, and I can only speak for myself, I was never aware of it. As soon as somebody reported it we fixed it. It's likely that it has been reported before and was not fixed then, but we saw the seriousness of the bug when it was reported this time and addressed it immediately.

Possibly adding fuel to the fire: Since the behavior has existed for so long and people have had to implement workarounds, you will have to enable the fix with the -eventfix 1 startup parameter. We will consider making the fix enabled by default but one of our goals is to ensure that existing applications run without changes when upgrading so we always take that into consideration in making such decisions.

Posted by Simon L. Prinsloo on 23-Mar-2016 09:35

I do notice that the bug number is quite new and I am extremely glad that it will be fixed. I appreciate that a lot.

In fact, I struggle to get one customer to move beyond 10.1B and the mere fact that the fix is in the pipeline will strengthen my case a lot.

We've come a long way since I first encountered that bug and much has changed.

We tripped over it a lifetime ago. That was before easy access to nice internet portals and support in our own time zone. A hot fix would come on a CD, mailed to us a week before from the US. Then we would need to copy and courier it to customers in other countries.... Even if the ESD existed, the internet was so slow that the CD would beat a download by days.

What I try to say is this:

We can normally have two situations. One is sad, with a possible happy ending for everybody, one is about winners and losers. It all depends on how we reject something in the beginning.

Sad Story (Vendor cannot satisfy and customer, neither like it.)

- Bad news. It is a bug. we are not in a position to fix it.

Happy Ending (Vendor makes a difference for customer. Both elated)

- This was (re)discovered / we looked at it again. We are now in a position to fix it. Watch this space.

Winner and looser

- Vendor (winner) sugar coat the matter and refuse to fix it, brush it under the table. Customer (looser) left out in the cold.

- Vendor (loser) "cave" and undertake to fix it, admitting that the customer (winner) was right all the time.

As programmers we often run into situations where we are changing a sad story into a happy story, just to find that the user is not celebrating the breakthrough with us, but a victory over us in a long forgotten war started by someone who may be long gone.

I guess the point of the thread, for me, is this:

Don't be a hard-ass winner today, rather share the user's pain. That way the guy who fix it can celebrate with the user, rather than being confused about a user's victory dance. Who knows, it might be you.

This thread is closed