Sherlock Holmes and the Case of the Missing Events

SRP has a good reputation for tracking down the obscure and unusual problems that occasionally occur within OpenInsight. Normally we should prefer that these problems be far and few between (especially when trying to impress a client!) but like a good mystery novel, there is something about the challenge that presents us with a thrilling adventure.

Such was recently the case when I upgraded a customer’s system from OpenInsight 4.1.3 to OpenInsight 8.0.8. Great care was taken to make sure all necessary upgrades were applied as skipping some can create incomplete systems. At first glance the upgrade path appeared to go flawlessly. Beyond the known form fixing issues, the application worked just fine. That was until I recompiled my first form…

All of a sudden my CREATE event handler was failing to execute. So the first place I investigated for clues was the QuickEvent dialog for the form. Upon arriving I found that none of the typical form specific events are available. CREATE, READ, WRITE, DELETE, CLEAR, CLOSE, etc., were all gone. In their place were the standard events associated with the static text control (see above image.) Well that simply wouldn’t do! Thus, the investigation continued.

A fairly common reason for event issues is when the CFG_EVENTS record within the SYSENV table becomes corrupted. In fact, this has been known to happen with OpenInsight upgrades. I was almost willing to bet good money that this was the issue. So I quickly ran the Event Designer to confirm my theory, only to learn all too quickly that my theory was incorrect. The content of CFG_EVENTS was perfectly intact. This proverbial Moriarty continued to thwart me.

Well certainly someone else had encountered this problem before so I went to the fount of all OpenInsight knowledge: The Revelation discussion forums! It wasn’t too difficult to find some posts in the general discussion forum that described my problem. Sure enough, the common suggestion was to check the CFG_EVENTS record. Okay, been there, done that. One thread showed some promise as Sean FitzSimons (a Revelation Software employee for those who do not know) got involved after the original poster indicated that nothing was wrong with CFG_EVENTS. I followed the trail of this discussion eagerly waiting for the missing piece of this mystery to be revealed until I got to Sean’s final entry:

This thread is continued in the WORKS section under “An answer is required please” – Sean

Okay, so I just need to focus my search in the WORKS discussion forum. Easy enough…except the WORKS discussion forum has recently been converted from Lotus Domino to O4W. Try as I might, I could not find this thread anywhere in the WORKS discussion forum. I believe the primary reason for this is because only two years of WORKS discussion threads have been ported over to the new O4W system whereas the original discussion dated back to 2004. Foiled again!

Despite this apparent roadblock, I did uncover a helpful clue. In a similar, but much newer, discussion thread I read that this problem had occurred during a beta upgrade but was subsequently repaired. Unfortunately the nature of the repair was never documented. Since I was careful to only apply official (i.e. non-beta) upgrades I didn’t think this was relevant…but it was the best clue I had so I decided to chase after it. This meant I was going to have to blow the dust off of my detective kit and dig a little deeper.

I reasoned that if this problem was related to a buggy system component then I should be able to locate the culprit and replace it with a version from a known working copy of OpenInsight 8.0.8. Those of you who read the blogs of our good friends Sprezzatura know there are many ways to profile OpenInsight. One of the oldest, and easiest, methods is to use the OpenEngine log feature:

So I started a new log and then opened the form with the Form Designer and then went to view the events in the QuickEvent dialog. After closing the OpenEngine log I went to examine its contents. One entry stood out:

****************************************************************************** 
Begin processing time: 9/15/2011 22:55:24 
RUN FORMDES_SUB 'GETEVENTINFO' 
Stop processing time: 9/15/2011 22:55:24 
Execution time: 0 milliseconds. 
Execution status: successful. 
******************************************************************************

My instincts led me to check and see if $FORMDES_SUB was different in this copy of OpenInsight compared to a working system. For me the easiest way to do this is to use the SRP Editor. One of the nice features that has been a part of our utility is the ability to examine the compiled object code of stored procedures. Alas, the versions were identical so it seemed that once again I reached a dead end…almost.

I was convinced I was on the right trail but I just needed to follow it a bit further. Again, the SRP Editor came through for me. One of the helpful bits of information buried within compiled object code is the list of stored procedures that get called. This is where I found a reference to $OIWIN_GETEVENTINFO. Aha! Could this be the answer to the riddle I’ve been trying to solve?

With great joy I was able to determine that this version was, indeed, much older than the version in my working copy of OpenInsight 8.0.8. Using the often useful (but under appreciated) Entity Check-Out utility, I was able to restore this routine in no time at all. A quick test of the Form Designer proved that I had finally solved the mystery.

Once again we see the advantage of the Revelation philosophy that (virtually) everything in the toolkit is really a database row within a database table. I couldn’t imagine fixing another toolkit in quite the same way. Another valuable lesson to be learned from this is to make sure you always have a clean, unmodified, copy of OpenInsight lying around. In our labs we have a “clean” copy of OpenInsight for every version from 4.1.3 through 9.2.1. These can be lifesavers.