One of the intermittent problems we face when developing with OI 10 is knowing about the new properties and features that we now have access to. The pace of development is so rapid that the documentation just doesn't keep up. There's a fine source of documentation at revDevX.com along with multiple blog posts at the same site but sometimes the Lord helps those who help themselves.

With this in mind, we'll use a real world example to illustrate how much easier life can be when we have access to such new features.

We recently wanted to have a radio button contract or expand based upon a control record. We knew how we would have accomplished this in the past - we'd grab the button control object, destroy it, modify it then recreate it. That's all well and good, it works and the control stays at the right place in the tab order - but it can change the Z-Order of the control which isn't always desirable.

Naturally we wondered if there was a better way in 10.

Of course there is, or we wouldn't be making this blog post.

Taking a simple example where we want to alter the available buttons based on the membership type, we'd have one set of radio buttons for the member type and another for the letter type.

We all like to boast that OpenInsight is written in OpenInsight but the implications of this can be missed in the excitement of the new environment. We're so used to OI not exposing all of a control's properties that we lose track of the possibility that what we need may be staring us right in the face.

The simple fact is, that if something exists in the property panel in the form designer for a control, then it is an exposed property. So let's look at the property panel for a radio button.

Clicking on the options button displays a dialog containing the text and values for the radio button :-

So now, to accomplish the above goal all we have to do is manipulate this property. Here's a simple code snippet to do this :-

If you're not familiar with the syntax being used for getting and setting properties check out the blog post here.

We'd encourage you to take a look around the property panels to see what other goodies you can find!

 We've been doing a lot of stress testing of LH at Sprezz Towers to help a client with speed issues on large tables. As part of that we've created some 60 million row tables to play with combinations and permutations of differing indexing setups.

In so doing, we came across a situation where the index sort would get to 80% and then just exit with an FS220 error. (FS_REL_NEED_REBUILD_ERR$). Now to be honest, this was confusing to us as there wasn't a relational index on the table. So speaking to the good folks at Rev, it was clarified that this was the wrong error but for fairly obvious reasons we were the first to notice. After discussing further with them we came to the conclusion that it must be related to disk space.

So began an increasingly frustrating attempt to free up disk space (why oh why did I format my USB sticks with FAT32 and its 4GB file size limit?). Subdirectories were zipped, old files deleted until - finally we had the 40GB or so free that we needed. 

We tried again - and again around the 80% mark the index rebuild just stopped. It didn't crash, it just stopped - having cleared out the %ALL.IDS% token in the ! file.

As V119 was suspected to be the culprit, we redirected the temporary sort file in the environment to the same disk as the data tables so that we could keep an eye on what happened. 

78% and still going

and then - boom

It seems that the largest sort file that can be created is 2GB and that attempts to exceed this will fail. Note that this applies to both IDX_SETS1 and 2. This is a limitation of a 32 bit OS rather than OpenInsight, so can not easily be addressed in version 9.x.

This will probably be obvious to most, but it's been a real thorn in my side since day one of OpenInsight, and by day one I mean alpha testing and writing bits of OI 2.0 back in my apk@revelation.com days.

I've always had trouble remembering which property is LIST and which property is ARRAY.  Every time I use these, I either get it wrong or just load HELP to check which one is column by row and which one is row by column.  Finally, with a little help from Captain C, I have a working mnemonic.

ARRAY == Across, because the data moves across the table.
LIST == Lines, because the data comes back line by line.

Finally, almost 28 years later, I can stop searching HELP daily.

 Over the years, we've had numerous queries as to what exactly clientsetup.exe does and why it has to be run on each and every machine that will be running OpenInsight. With the help of RTI stalwart Bryan Shumsky, we've put together this post to tell you all you need to know about client install.

Over the years, OpenInsight has evolved from a pretty much self contained environment, where you could just pick up an application folder, move it elsewhere and expect it to work, to an environment which requires increasing levels of workstation adaptation. Firstly the OIPI print engine required that an OCX be registered at the workstation before it could be used. Of course, the OCX could still reside on the server, so all that was required for the client was an OCX registration via REGSVR32.EXE. The same went for the AREV32/64 command window. Then the new scintilla editor.

But as more of OI began to be developed in external languages, (specifically .NET) the requirements became more onerous. Windows doesn't take too kindly to being asked to run .NET components over a network and to make it happen, various security overrides need to be put in place. These are beyond the capabilities of a run of the mill installation script, so the decision was taken to install the .NET components locally on the workstation and to register them there. At this point it's important to add that you MUST install these assemblies on the local machine not on a network drive,

For reference, it is worthwhile pointing out that whilst historically the client setup is run from the OINSIGHT subdirectory, it can actually be run from any location as long as the "Assemblies" and "Client Files" subdirectories exist (with contents) relative to the clientsetup.exe.

With Bryan's help we were able to put together this list of what actually happens during a client install. So with no more ado, here's what the program actually gets up to...

First things first. Check if the client setup has already been run at some stage on this workstation - so it's off to the local registry the program goes. This makes it easier for the program to suggest defaults for the new installation.

Next, just to be nice, the program sets up shortcuts to the documentation, website etc etc.

Then, checks if there are already existing .NET assemblies at the requested installation location. If there are, they are removed. This is to stop the installation process interjecting with annoying messages about pre-existence etc.

Penultimately it then copies the files from the aforementioned subdirectories (Assemblies, Client Files) to the specified location on the local machine.

It then finally registers and installs the OCXs and .NET assemblies at their new local location.

Of course, there are circumstances where the client install might not be needed - for example if your installation doesn't need to edit, print, or sort information. Paradoxically this does mean that if you're running the engine server on the network server, you must ensure you do the client install on that machine too!

Hopefully this information will help you in understanding your deployment issues, and a big shout out to Bryan for helping with this.

Like many Revelation consultants, we have a number of clients who continue to use decades old software under new, more modern technologies - specifically AREV32/64. A technology that was meant to provide a transition path to a more modern UI is frequently just used as a way to continue taking advantage of the massive ROI provided by Revelation Software - in this case AREV.

But sometimes, things go wrong. And this week we were bitten by a particularly pernicious bug that we hadn't seen before.

The client reported that suddenly, blank documents were being emailed to their customers rather than the order confirmations that they were expecting. Investigation was relatively easy - isolate the section of the code that creates the files and test this. The section of code in question simply executed a PDISK to redirect printer output to a file, produced the report, then PDISK PRNed to cancel the redirection.

Upon testing, it failed to produce any output, despite reporting that the redirection was successful. Following Occam's Razor we tried to reproduce the issue by issuing a PDISK at TCL, performing a simple LIST report to disk, then doing a PDISK PRN. Surprisingly, no disk file was produced. 

So we reverted to an older version of the software and tried again - regretfully with the same result. It didn't matter how far back we went, the error persisted. At this point it became obvious that this was not the issue that the client was facing - all had been well until the last upgrade - but it WAS an issue that we were facing in our testing. But our software was a direct copy of their system, so what could it possibly be?

We tried calling SETPTR directly, we tried different filenames and different extensions but to no avail. So it was time to roll out the big guns and deploy PROCMON, the stunningly useful utility from SysInternals available from Process Monitor - Windows Sysinternals | Microsoft Docs. We reproduced the lack of output with PROCMON running and examined the captured output. We filtered the output on process OENGINE.EXE and path containing ZZZZ.txt and saw 6 entries as below :-

The first 4 were as expected, but the last two were strange to say the least. The spaces in our directory path had been replaced with underscores - and strangely, Windows could not find a path with that name.

This provided us with a working theory - so we copied the system to a subdirectory with no spaces in the name and repeated the experiment. This time we saw the results we expected - a file containing output :-

and the PROCMON trace showed no errors

So it would seem that PDISK has been engineered not to work with subdirectories containing spaces in the path. 

 With more and more applications (in Europe at least) moving to UTF8 we got to thinking about the inherent limitations in case conversion for developers in OpenInsight. Historically developers have changed from lower to upper case by simply converting @lower.case to @upper.case in the string to be converted. This is all well and good in an ANSI system but could create issues in a UTF8 system.

The strings @lower.case and @upper.case aren't magic - they are just text strings loaded by the system at startup, and there is no way that they can easily be made to contain all of the characters necessary in a UTF8 system. Naturally we could manually load them with all of the characters that we think might be required but the strong chances are we'd miss something, and in any case it's 2021 - there has to be a better way right?

Right.

Of course there is - it's an issue all Windows developers face - not just Rev developers. So naturally Microsoft have made it easy by providing two exported DLL functions for developers to use, namely CharUpperW and CharLowerW. (For an explanation of why we are using the W version rather than the A see this blog entry). These functions do the conversion of the string "in place" - so we simply have to call them passing in the string to be converted and it will be changed in the string (rather than returning a changed value).

The only drawback is that to be able to use it, we have to prototype it first in a DLL definition. Historically this was a messy process, involving creating a DLL Prototype for the functions, saving it and then running a system routine called DECLARE_FCNS against this definition. If you're not familiar with this, where have you been for the last decade or so? ;). Then if we wanted to track the definition for deployment we'd have to create an APPROW definition because the OI Repository didn't know about the existence of DLL prototypes.

Fortunately in OI 10, DLL Prototypes are now part of the OI entity family and as such there are UI tools to accomplish all of the above. So let's see how we'd go about defining the above two functions.

Let's go to File/Entity/New

and select DLL prototype record. The DLL Prototype Designer launches and we can define our functions. Let's start by telling it that the functions we need are in USER32 and define a namespace (a unique string to prepend to the name of the function so that somebody else's (potentially incorrect prototype) definition doesn't overwrite ours). This particular function doesn't return a value  so we're going to use a return type of VOID :-

and it takes an LPWSTR type

Then define the arguments for both functions

and apply the namespace (to which I've remembered to add an underscore :))

Then save it using Ctrl-S

The system obligingly tells us that is has saved the prototype

and finally we can compile the prototype (running DECLARE_FCNS effectively) by pressing F9

We can check that the system functions as in version 9 by checking for the DLL_ row in SYSPROCS

and sure enough - the only difference in 10 from 9 is that there are now comment lines for the namespace and comments :-

The routines are now available to us to perform UTF8 compliant lower and uppercase conversions. So "convert @lower.case to @upper.case in string" becomes "call zz_CharUpperW( string )" and "convert @upper.case to @lower.case in string" becomes "call zz_CharLowerW (string )". Of course there's nothing to stop you aliasing the functions to more friendly names like "toUpper" or "toLower" but there's always the chance of a clash with existing names. 

The Challenge

The Chosen Solution

ROWID

Type of Pointer

Blank

File to find Object in

Name of Object

RBASIC

SYSOBJ

SET_PROPERTY.

The First Hurdle

The NEXT Chosen Solution

A World of Pain, BFSs and Virtual MD Files

A Little Bit On The Program Loader (RTP27)

Baby Steps

Code Coda

Business Logic

The Final Program