[progress Communities] [progress Openedge Abl] Forum Post: Taking The User For A Ride By...

[Simon L. Prinsloo]

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

Continue reading...