SRP Product News

Sherlock Holmes and the Case of the Missing Events

Don Bakke — Fri, 16 Sep 2011 01:42:28 -0500

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.

It's the Little Things - Resolving a Long Standing SRP FrameWorks Annoyance

Don Bakke — Thu, 15 Sep 2011 02:52:34 -0500

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$

An Explanation of SRP's Licensing Policy

Corby Nagel — Wed, 18 May 2011 16:48:16 -0500

SRP's philosophy on product licensing has always been geared toward the developer rather than the end user. As such we have always provided a "royalty free" licensing policy. That is, a developer only needs to buy one license which can be deployed with any application that the developer supports. While this may seem simple in concept there are some technical considerations that can sometimes create confusion for our customers.

In many development environments third-party products can be registered within the IDE so that the developer can program and test without an evaluation (or "nag") message. Deployed applications are embedded with the necessary information to permit end users unrestricted utilization of systems using these products. While OpenInsight provides a similar method to support third-party controls, SRP has chosen to implement control through our SRPLicense.dll file.

SRPLicense.dll

This single file contains the following information:

The name and contact information of SRP's customer.
The product(s) which have been licensed by the customer.
The version of each product that the customer is licensed to use.
The serial number(s) that the customer needs to support.

Therefore, adding new products or serial numbers is relatively easy. All we need to do is update the information within the SRPLicense.dll and send this to the customer for deployment. Using this method also eliminates the need to cripple our products. Without a properly updated SRPLicense.dll the product will simply display an evaluation message¹ but otherwise be fully functional. Conversely, developers can install upgrades to licensed products without needing to update their SRPLicense.dll ²

Serial Numbers

Since our goal is to equip the developer to create better applications, we recognize the need to support multiple serial numbers. This includes the developer's own WORKS license as well as any supported Runtime Class and Developer Class licenses³. Fortunately Revelation Software have adopted a policy of assigning developers with a unique four digit prefix that is used in all serial numbers. Our licensing technology allows us to support this prefix so that we do not have to regenerate new SRPLicense.dll files whenever a new serial number has been assigned by Revelation Software.

Versions

Currently all SRP products follow the major.minor.revision model of version identification. For instance, as of this writing the version of the SRP EditTable Control is 2.2.9. Customers are entitled to free upgrades within the same major release of any product⁴. Therefore a customer who purchased 2.0.0 of the SRP EditTable Control will be permitted to upgrade to 2.2.9 without additional charge. However, a customer with the 1.0.0 version of the SRP EditTable will be subject to an upgrade fee. Using a product with a higher version number than is supported by the SRPLicense.dll will invoke a version mismatch message.

We trust that this helps explain the intent of our licensing model. If you have any further questions please contact us at info@srpcs.com

¹ Evaluation messages appear when there is a missing SRPLicense.dll or if the current SRPLicense.dll does not include the current product being used. If the SRPLicense.dll does not include the current OpenInsight serial number then a serial number mismatch error will appear. Another error that can appear is a version mismatch which occurs when a licensed product is used but the license only supports an older version.

² This assumes that the developer is upgrading within the current major version supported by the license.

³ One exception to the above policy is when a developer requests a license for another developer (or a customer who has their own WORKS license.) In these situations we treat the other WORKS license as a separate developer and will charge accordingly.

⁴ In the near future all SRP products will undergo a change in upgrade policy. Information about this will be posted in our Product News blog.

SRP Utilities Update, Version 1.3

Kevin Fournier — Tue, 06 Jul 2010 13:43:41 -0500

Once again SRP delivers features that OpenInsight developers can really use. We begin by addressing what amounts to be a branding and marketing problem for software products based upon OpenInsight. The issue occurs when Windows groups icons in the taskbar. Once this occurs, the button's title becomes "oinsight", even if the application was using the SRP Application Launcher utility. This is undesirable for commercial products since users usually have no idea what "oinsight" is. With the new SRP_Taskbar method we can alter the group button text to be anything we wish, thus preserving a software product's essential branding.

It's important to note that setting the taskbar group title only works in Windows Vista and earlier. Windows 7 uses an entirely different protocol for it's taskbar, and a solution is in the works. Look for it in the 1.3.1 release.

Also new to this version of SRP Utilities is the SRP_TcpClient method. It creates a TCP/IP connection to a running server and sends data. It's very low level and designed for those that have no other API to access a server. We have plans to augment the method with server-specific functions to simplify use. For example, SRP_TcpClient has special commands for communication with the SRP Engine Server. Likewise, we would like to add support for the OEngineServer and other TCP/IP protocols.

Lastly, we've improved both SRP_Join_Arrays and SRP_Sort_Array. SRP_Join_Array now supports two more merge options: NOT and XOR. The NOT operation keeps everything in the first list that doesn't appear in the second list. The XOR operation returns all items that appear in one list or the other, but not both. Combined with the existing operations (AND and OR), this should cover all the ways in which you might want to combine a list of keys. SRP_Sort_Array has been improved in the way it performs right-aligned sorting. Originally, it would convert the column into floating point numbers and compare, but this would not work with data that had alphabetic characters. For example, it wouldn't correctly sort "Box 1", "Box 2", ... "Box 10". SRP_Sort_Array now performs true right-aligned sorting in the event that it cannot convert the data into binary floating point numbers.

If you are currently using version 1.2.3 or earlier, we highly recommend upgrading. Both existing users and those that wish to try this free utility can download the latest version of SRP Utilities from here.

SRP Editor Update, Version 2.3.5 & 2.3.6

Kevin Fournier — Mon, 25 Jan 2010 12:31:30 -0600

The SRP Editor saw a new update last week, another minor fix to the code formatter, resulting in version 2.3.5. However, before we could get around to announcing it, we made a much needed improvement to the SRP Editor's command line.

Our command line has always suffered when it comes to executing built-in routines. To give you some background, when you run any routine, the SRP Editor command line opens the routine's object code and determines how many parameters the routine expects. If you pass too few parameters, the SRP Editor passes null values for all the missing parameters to avoid potential VNAV errors. This, of course, only works for routines that exist in object code and list their parameters. For all other routines, the SRP Editor command line just sends the parameters you provide.

This becomes a headache when using common built-in routines such as COPY_ROW. COPY_ROW hates missing parameters, and you'll get a VNAV error if you forget even one. If permitted, we'd like to appeal to the old saying, "Better late than never."

The SRP Editor 2.3.6 now ships with a default list of routines and their parameter counts. You can browse or modify this list in the new TCL tab of the Options dialog. Don't worry about modifying the list, the SRP Editor will never overwrite your changes. Most users will not really need this as the most important built-in routines are already there, including COPY_ROW.

SRP Editor 2.3.6 is now available to download from here.

SRP Editor Update, Version 2.3.4

Don Bakke — Mon, 14 Dec 2009 02:18:46 -0600

'Tis the season for...SRP Editor updates. One of our customers has a knack for finding issues with our code formatter. In this most recent scenario, it appears that our formatting logic was failing to ignore a "for" statement when it was located within a commented line. As a result the remaining code was being improperly intended. SRP Editor 2.3.4 has addressed this and is now available to download from here.

SRP Editor Update, Version 2.3.3

Don Bakke — Tue, 01 Dec 2009 20:36:10 -0600

We recently received a report that the SRP Editor would produce the above error message when attempting to close a record with unsaved changes. When we looked at the code we discovered that this issue would only happen when the Window -> Close All menu option was selected.

The fix required less effort than creating a new install. Nevertheless, we dislike problems with our products no matter how trivial they are. Therefore we have fixed this in SRP Editor 2.3.3 and posted it here.

As an added bonus, here is a little known tip that you might be interested in: from the SRP Editor use Shift-F7 to bring up the Viewer display (unless it is already visible then skip this step.) Then enter history in the Command Line. This will give you the change log for the SRP Editor broken down by version number:

SRP Utilities Update, Version 1.2.3

Kevin Fournier — Mon, 09 Nov 2009 16:06:45 -0600

SRP Utilities has been enhanced yet again with SRP_Join_Arrays. This function is useful for those of you that implement your own cross references. On several occasions, the developers at SRP Computer Solutions, Inc. have found themselves with two lists of keys they would like to merge. Sometimes, they need to get the keys that appear in both lists: an intersection. Other times, they need to merge both lists together without duplications: a union. SRP_Join_Arrays can do this for you at top speeds.

This version of SRP Utilities also contains a bug fix. SRP_Clean_Array has a TRIM option that--per the documentation--is supposed to remove only trailing blank elements from the array. This was not happening. Instead, it was removing all blanks in the array. This error has been corrected.

If you are currently using version 1.2.2 or earlier, we highly recommend upgrading. Both existing users and those that wish to try this free utility can download the latest version of SRP Utilities from here.

Did You Know - Managing RDKs from the SRP Editor

Kevin Fournier — Mon, 19 Oct 2009 17:30:56 -0500

Like most developers, the programmers at SRP Computer Solutions, Inc. love making tools that simplify complex tasks and make us more productive. With so many tools, it was only a matter of time before we created a tool to help manage our tools, specifically, the deployment of our tools.

Repository Deployment Kits (RDKs) are the means by which we deploy our tools such as SRP Editor, SRP Utilities, etc. As such, we found ourselves expending a lot of time and effort on just the RDK management. Maintaining RDKs requires several steps and a separate tool. Since we spend so much time in the SRP Editor, it seemed natural to enhance the SRP Editor with time saving RDK tools. This thought process led to the "Add to RDK" menu and the RDK command.

Add to RDK

The "Add to RDK" tool is accessed via the Tools menu or by pressing F6.

Doing so opens the "Add to Repository" dialog.

The purpose of this tool is to make it simple to add or remove a stored procedure to an existing Repository View. The process looks like this:

Open a Stored Procedure
Press F6 or choose the Tools -> Add to RDK menu
Use the check boxes to add/remove the active Stored Procedure to/from an RDK

In the screenshot above, you'll notice three check box columns. This allows you to specify which parts of the Stored Procedure are included in the RDK: Source, Debug, and Object. The screenshot shows a good example of this. Each of our tools has two RDK's, one that includes all source code, in case we need to deploy the source code to another environment for testing, and one without source code, which we deploy to the end users. Anytime I add a new stored procedure to a toolset, such as our SRP Utilities, I can quickly add it to the appropriate RDKs in just a couple easy steps.

You can also use this tool for Inserts:

Notice there is only one column, since there is no concept of object/debug code for inserts. You can also use the "Add to RDK" tool for Records:

Like inserts, there is only check box column. A record is either added to the RDK or it is not. Note that any records will be added to the repository view as an APPROW entity. We have plans to make this smarter in the future, but for now, if you need to add a popup, message box, or form to the RDK, you need to use the RDK tool built into OpenInsight.

RDK Command

The RDK command simplifies the process of exporting RDKs. Those familiar with OpenInsight's RDK tool have likely encountered the caveats involved in exporting an RDK to a folder. For example, the folder must already exist and be empty. The RDK command eliminates these quirks and provides a very powerful additional feature. First, let's look at the command line syntax:

RDK [INSTALL|EXTRACT] SourceList [(options)]

The RDK command's first parameter is optional (see the Installing RDKs section below) and it determines whether or not we are installing an RDK or creating one.

Installing RDKs

To install an RDK, the equivalent of running the "RUN RDKINSTALL" statement in OI, follow the RDK keyword with the INSTALL keyword or omit this parameter altogether. The SourceList portion of the statement is a list of paths containing the RDKs we wish to install. As the name suggests, you can install multiple RDKs in a single call. Both of the following command lines work:

RDK INSTALL "C:\RDK\SRP_Editor_Rdk" "C:\RDK\SRP_Utilities_Rdk"

RDK "C:\RDK\SRP_Editor_Rdk" "C:\RDK\SRP_Utilities_Rdk"

There are no options when installing RDKs. Simply provide the list of RDK paths. The quotes are only necessary if the paths contain spaces.

Extracting RDKs

To extract and RDK, you must include the EXTRACT keyword and a list of one or more RDK deployment definitions. Recall, the RDK's destination directory is defined in the deployment definition and is therefore not supplied in the RDK command. As an example, here is the command to deploy the SRP Editor:

RDK EXTRACT SRP_EDITOR

Now, as is, this command will operate exactly as the OI RDK tool, failing if the directory does not exist or is not empty. This is where the options come in. There are three options: C, S, and V. The "C" option clears the destination directory before extracting the RDK. The "S" option creates the directory if it does not already exist. So, to ensure a successful extraction every time, use this command:

RDK EXTRACT SRP_EDITOR (CS)

The "V" option is useful for creating RDKs that target multiple versions of OpenInsight. To illustrate, the SRP Editor is developed in OpenInsight 7.0, then extract using the "V" option to create 7.1, 7.2, and 8.0+ compatible versions of the RDK. What do we mean when we say compatible? First, any presentation server changes between version are taken into account. Thus, any forms created in 7.0 are form fixed in the 7.1 and later RDKs. Secondly, each RDK version is given the appropriate RDKMODULEINSTALL for that version.

NOTE: There are no currently no RDK versions created for 9.x because the 8.0 RDK works in those versions of OI as is.

A final point of interest is that the "V" option only creates RDKs starting with the version of OI from which the command is executed. That is, if you run the RDK EXTRACT command in OI 7.2, then the "V" option will only create the 7.2 and 8.0 RDKs. So, our final command can look like this:

RDK EXTRACT SRP_EDITOR (CSV)

And since a list of deployment definitions are supported, we can extract several of our tools in one call:

RDK EXTRACT SRP_EDITOR SRP_MAIL SRP_UTILITIES (CSV)

It's our hope you find either of these tools useful in your own environment. We welcome your feedback on how to improve these tools. If you haven't tried the SRP Editor, you can download a free trial from here.

Did You Know - Accessing Images from Compressed Folders

Don Bakke — Sat, 10 Oct 2009 11:16:29 -0500

OpenInsight's BITMAP property allows developers access images by path name or from within a resource file (.DLL or .EXE):

// Pull image from a path.
Set_Property(Ctrl, 'BITMAP', 'BMPS\Check.png')

// Pull image from a resource file.
Set_Property(Ctrl, 'BITMAP', 'Images.dll#check')

Storing images within a resource file makes an application more professional and prevents the curious end user from modifying the images stored on the hard drive. However, many developers are unfamiliar with the technology necessary to manage images from within a resource file. Most software development kits provide tools for this. If you are unfamiliar with (or would rather not learn) these SDKs there are simple utilities that can be downloaded to make this relatively easy (e.g. one that seems to work well is Resource Hacker.)

As might be expected, all SRP ActiveX image based properties can load images from a path or resource file. However, for developers who like the idea of using a single file to store all their images but would rather not fiddle with resource files there is another option: zip files. Developers can put all of their images into a zip file (aka compressed folder) and use the same syntax to reference them. The .zip extension can even be renamed to obscure this even more:

// Pull image from a zip file.
Set_Property(Ctrl, 'OLE.Images', 'Images.zip#check')

// Pull image from a zip file (extension renamed).
Set_Property(Ctrl, 'OLE.Images', 'Images.fil#check')

Don't forget that the entire SRP ActiveX control suite and OLE Help documentation can be downloaded from here. These are fully functional controls but will display an evaluation message without a license file.