It’s the Little Things – Resolving a Long Standing SRP FrameWorks Annoyance

From the earliest days of our venerable FrameWorks product there has existed a rather annoying problem whenever the System Monitor was launched: OpenInsight would lock up and the only way to recover was to use the Window’s Task Manager to kill OpenInsight.

Of course we’ve known just what was causing the problem and we certainly wanted to get this fixed but it never became a high priority. After all, we became accustomed to avoiding the combination tasks that resulted in the unforgiving problem. While this might be just fine for SRP developers, it has become something of an embarrassment when other developers who use SRP FrameWorks for their own projects contact us wondering why their system locks up when they run the System Monitor.

Such was the case when one of our more recent customers (thanks Clay!) submitted the following note:

I experienced a possible issue in frameworks. If you open OI, then F12 for the system monitor, then launch app – OI hangs. I’m not sure what it is hanging on. Let me know if you are able to duplicate this.

Of course, I gave the familiar response…this is a well-known problem, this is not a bug per se, and the clincher – just don’t run FrameWorks and the System Monitor at the same time! Well, this time I was on a short break of a road trip when I responded. When I continued my drive I was forced to think about the nature of the problem (which is explained below) and a potential resolution. Perhaps it was the humdrum of the road that held my mind as a captive audience, but whatever the reason a rather basic workaround came to me and as soon as I got to my destination I broke out my laptop to test my theory. It worked!

The reason SRP FrameWorks (when running) and the System Monitor don’t get along is rather simple. When the primary MDI Frame window (FRW_MAIN) is launched, a hidden edit line control is setup as the STATUSLINE for the application. This is done so that help text associated to menu items or push button controls can be captured and routed to the SRP StatusBar control. However, in order to make this work we needed to capture the CHANGED event of the hidden edit line. So far so good.

SRP FrameWorks also uses promoted events. In fact, it’s a core part of the system. There are several event handlers which trigger on a regular basis. However, when an event handler executes this gets recorded in the System Monitor…which also sends an update to the current STATUSLINE control (this is easy to observe safely…just run the Database Manager and the System Monitor together and note the changes being displayed in the Database Manager’s statusbar edit line control.)

Herein is the problem. Our promoted events are constantly updating the System Monitor which then updates our hidden edit line STATUSLINE control which then triggers the CHANGED event and thus locks up the system (hmmm…perhaps another reason for multi-threaded support.) So the solution is rather simple: just turn off the STATUSLINE property when FrameWorks and the System Monitor are both running. Easy enough, but how can we automate this without having to do this manually?

Fortunately OpenInsight has many Windows’ API functions prototyped. One of them is FindWindow(). This API returns the handle of a running window based on its class. For the System Monitor the class is RTI_PSMonitor. How did I know that? Well this is where one of several free and commercial spy utilities comes in handy. In my case I used a very simple program called Handle Spy. However, the System Monitor is always running but it isn’t always visible. So seeing if the handle exists is not enough. We also needed the services of IsWindowVisible() to give us our final piece of evidence.

The rest is elementary. During the CHANGED event of our hidden edit line we simply check to see if the System Monitor is visible. If it is then we disable the STATUSLINE property. Thus the perpetual triggering of the CHANGED event ceases and the system is able to be used as normal. There is a caveat. Closing the System Monitor will not enable the STATUSLINE property to our hidden edit line so none of the help texts will get passed to the SRP StatusBar control. However, a quick restart of FRW_MAIN will resolve this. There is probably yet another workaround to deal with this secondary problem, but that will have to wait for another day. For now here is the code that should replace the CHANGED.EDL_FRAME_STATUS gosub within FRW_MAIN_EVENTS that all contemporary versions of SRP FrameWorks can use to avoid this irritating problem (much order systems should be able to adapt this code fairly easily):

MonitorHandle   = FindWindow('RTI_PSMonitor' : \00\, ) 
MonitorVisible  = IsWindowVisible(MonitorHandle) 
If MonitorVisible then Set_Property(@Window, 'STATUSLINE', ) 
Set_Property(@Window : '.OLE_FRAME_STATUS', 'OLE.PaneCaption[1]', Param1) 
EventFlow       = EVENT_STOP$