>Introduction to WebOI videos


The Introduction to WebOI videos are now ready and published to You Tube. However, please note that owing to video time limitations set by You Tube, the two videos have been split into two, leaving four You Tube videos in all. I will also be making these available as two zipped downloads shortly.

In the meantime, you can find the videos at:

1) Introduction to WebOI – Part 1a
2) Introduction to WebOI – Part 1b
3) Introduction to WebOI – Part 2a
4) Introduction to WebOI – Part 2a

Part one is a PowerPoint presentation that looks at what WebOI is, who it is for and provides a brief architecture overview.

Part two takes a look at my IIS7 settings for Vista and then we run through converting an OpenInsight form for WebOI and to run with a commuter module.

>WebOI under Vista and IIS7 Quick Start Guide


As many of you will know, throughout the 9.0 beta program I have been working on a Vista machine. Following the commercial release I have continued and more recently worked through configuring IIS7 under Vista for WebOI. Whilst I would advise you to take professional advice on configuring IIS7 in a live environment, I have written up my experiences in getting WebOI running under IIS7 on my standalone Vista machine.

You can download the WebOI under Vista and IIS7 White Paper from the UK Revelation web site.

>Shaded Table Rows in OIPI (now) and OIPI.NET for 9.0.1


Most of us print reports onto plain white paper these days, rather than the old report paper with pre-printed alternating white green rows/lines. For this reason, shading table rows in reports makes them easier to read, especially when printed landscape or on oversized paper.

This can be easily achieved in OIPI through a few lines of code added to the report’s stored procedure. The code is used to print each row of the table separately and to toggle the background shades between each row. For example:

Isappend = 0
Shading = 1
For each.row = 1 To num.rows
If shading = 1 Then
shading = 0
this.shade = rgb(220,220,220)
End Else
shading = 1
this.shade = rgb(0,0,0)
thisrow = table2
If thisrow = “” Then thisrow = ” “
x = Set_Printer(‘ADDTABLE’, ‘<840':@vm:'<960':@vm:'1200′:@VM:’>1200′:@VM:’>1440′:@VM:’>1440′:@FM, TABLE1, thisrow, ”, this.shade, isappend, TB_BOX_COLUMNS)
isappend = 1
Next each.row

As mentioned on the blog last week, not all of the old OIPI functionality works in OIPI.NET and this is another example. However, good to Revelation’s commitment to fix any issues that can be addressed internally, Bryan has already begun working on this requirement after it was raised with me by one of our clients, in fact I had an example within ‘four hours’ of suggesting this for a future release – now that’s service!!

For version 9.0.1, OIPI.NET has been modified so that it will work like OIPI in the example above. – that fixes the incompatibility issue between OIPI and OIPI.NET for those of you using the above example in your existing OIPI reports.

In addition, Bryan has made it even easier in OIPI.NET and added the ability to add multiple row colours. In an example that he sent to me the report has rows that alternate white-grey-red-white-grey-red, etc. This is achieved by specifying multiple shades in the background shade parameter (@VM-delimited), and OIPI.NET will alternate between the shades. For example:

ourshading = rgb(220,220,220):@VM:rgb(250,0,0):@VM:0
x = Set_Printer(‘ADDTABLE’, ‘<840':@vm:'<960':@vm:'1200′:@VM:’>1200′:@VM:’>1440′:@VM:’>1440′:@FM, TABLE1, TABLE2, ”, ourshading,”, TB_BOX_COLUMNS)
x = Set_Printer(‘ADDTABLE’, ‘<840':@vm:'<960':@vm:'1200′:@VM:’>1200′:@VM:’>1440′:@VM:’>1440′:@FM, TABLE1, TABLE2, ”, ourshading,’1′, TB_BOX_COLUMNS)

Please note that in this example 3 colours are defined, being grey, red, and nothing. The example also shows how the use of multiple addtables (with the ‘append’ parameter set on the 2nd one) properly keeps track of the alternating rows.

>OpenInsight 8.0.8 released

>The OpenInsight 8.0.8 upgrade is now available for download from The Works Download section on www.revelation.com. The upgrade can only be applied to OpenInsight versions 8.0.3 through 8.0.7.

New to OpenInsight 8.0.8 are enhancements to Arev32 and a fix to an error with LOSTFOCUS when FOCUS was lost to a non-OpenInsight window. The FOCUSID was unassigned. The FOCUSID is now set to NULL.

>A date for your diary.

>Guys – Please keep Monday the 23rd and Tuesday 24th of March free. Mike Ruane is planning on coming over for a whistle stop visit and we will be hosting an afternoon session in London during which we will be reviewing some of the new feature delivered in version, some insights into 9.0.1 and also ways that you can get more productivity from the recent releases.

In addition, this event will provide you with the perfect opportunity to put your future development requests to Mike in person.

We will be confirming a venue and which of the two dates sometime during next week and I will post more details as they are available. In the meantime, please drop an email to mp@revsoft.co.uk to reserve your place and give me an idea of the numbers that we need to accommodate.

Many thanks.

>Managing how your OIPI reports are run in version 9.0


Those of us upgrading older OI applications to version 9.0 will inevitably want to have some reports printed using the old OIPI print engine and others using the new OIPI.NET engine, especially where an old OIPI report is not fully compatible with OIPI.NET.

The OI help files explain how the default print engine can be defined in the CFG_OIPI record to run either the old OIPI engine or the new OIPI.NET engine released in version 9.0 – more below.

However, what happens if you want to have an old report run using OIPI and a new one to run using OIPI.NET? In addition, what if you want one user or one application to exclusively use one of the other? All of this is configurable within OpenInsight:

  • Default Behaviour
    The CFG_OIPI record controls the default behaviour for the entire system. Setting this record to VSPRINTER will run all OIPI reports with the old OIPI print engine as a default. Set the record to VSPRINTER2, and OpenInsight will default to use OIPI.NET.
  • Setting the default print engine by application
    You can configure the system to use one of the two print engines across a specific application by creating a CFG_OIPI* record in SYSENV. For example, CFG_OIPI*SYSPROG with a value of VSPRINTER2, will set all OIPI reports printed from the SYSPROG application to run using OIPI.NET. This setting will override any system wide default setting in CFG_OIPI.
  • Setting the default print engine by user
    A print engine to be used for a specific user can easily be configured in a similar way. In this instance, a CFG_OIPI** record will need to be created. For example, if there is a CFG_OIPI*SYSPROG*MARTYN record defined with a value of VSPRINTER, all reports that user MARTYN prints from the SYSPROG application will be printed using the old OIPI print engine. Again, the system wide default in CFG_OIPI will be overridden by this user-specific record.
  • Setting the print engine for a specific OIPI report
    Revelation has also catered for those of you with legacy OIPI reports that are not compatible with OIPI.NET and who also want to use OIPI.NET for printing to html or who want to use the many new features in OIPI.NET. In this situation you simply need to call SET_PRINTER2() and GET_PRINTER2() in your report’s Stored Procedure to use the OIPI.NET print engine or SET_PRINTER1() and GET_PRINTER1() to use the old OIPI engine. Once again, this method overrides the default setting in the CFG_OIPI record, leaving you the best of both worlds.

For most people upgrading older applications to version 9.0, the obvious choice is to make sure that the default engine is set to VSPRINTER in the CFG_OIPI record and then simply create your new OIPI.NET driven reports using VSPRINTER2 instead, or one of the app/user specific options. This removes the need to modify your hundreds of old tried and tested reports when upgrading to version 9.0.

>Vista running in compatibility mode.

>I’d planned not to post this article as I thought it was just me being stupid again. However, a recent conversation with a non-Revelation developer proved that Vista running all sorts of programs in compatibility mode can have consequences where the software is behaving in a certain way for the installed operating system. This posting is therefore more of a heads up than anything.

During the beta test program for OI 9.0 I let my license run towards its expiry date and I duly began receiving the notice that the period was about to expire. I clicked the OK button and continued to use the beta software without any problems. However, when I let the beta test run passed the expiry date I began to have problems on my Vista machine, although the same copy running under Windows 2003 Server behaved as expected.

Following a number of tests, my colleague in the US support team uncovered the problem. My machine, although running Vista, was reporting to OI that it was running XP. This lead him to research the issue further and he found that running in “Compatibility Mode” could cause the operating system to be reported as XP, not Vista.

Changing the shortcut properties to not run in compatibility mode resolved the issue and the license warning screen operated as designed – something else to watch out for when installing your OpenInsight system (and other applications) on Vista machines.

>Vista rollouts set to overtake XP

>Forrester Research recently surveyed 962 decision makers in companies operating in North America and Europe with regards to their adoption of the Vista operating system. During this survey they discovered that Vista deployments could shortly replace Windows XP as the operating system of choice in the enterprise.

An article published in on on http://www.computing.co.uk/ dated 5th February ’09, goes on to state that the study shows that Vista is currenty running on nearly 10 percent of corporate desktop systems. However, a third of those people surveyed said that they had already started rolling out Vista, with 26 percent citing plans to deploy later this year.

It goes without saying that as more of our users move to Vista, anyone deploying OpenInsight systems will need to begin to cater for the Vista operating system very soon.

The good news is that I have been running very successfully on Vista Home Premium throughout the 9.0 beta program and all of my work, demos, etc are now undertaken using the version 9.0 commercial release.

I have run into a few issues, one of which I have already highlighted on this blog (support for fonts between XP and Vista) and I’ve also had an issue the was a result of my Vista machine reporting itself to be an XP machine – watch for a posting on this coming very soon.

One of the few known issues is that of OpenInsight being left running in the task manager when OpenInsight is closed. It will not be any surprise to you that this reults in some undesirable behaviour. Revelation jumped on this issue very quickly and the latest RCL4.dll file resolves that issue. Although the previous link will give you access to the latest file, I would strongly suggest that you save a copy of your existing rcl4.dll file in case this new file gives you any problems. The official recommendation will be to upgrade to OpenInsight 8.0.7 or more preferably 9.0, to be as ready for Vista and Windows 7 as possible, especially as Revelation are offering 25% off the cost of OI WORKS during February ’09.

Note: Although I am using the lower end ‘Home Premium’ version, this is not going to be a supported version for use within networks. I would therefore recommend that you opt for Vista Ultimate or Business, preferably the former. It should also be noted that, as I understand it, there is no upgrade path from the Home Premium edition to Business. I would therefore suggest that you do your homework before purchasing a computer with Home Premium.

>9.0.1 Edit Table Teaser

>I have just had a sneak preview of an Edit Table enhancement coming in version 9.0.1 that I want to share with you. Once again, as a result of customer feedback in the EMEA region, Revelation have listened and acted. The request was for better visibility of the selected cell in an edit table – ideally something similar to the way the cell turns yellow in OpenInsight’s Table Builder.

It goes without saying that such functionality can be created using code on an edit table by edit table basis or through a promoted event for consistency across the application. However, for version 9.0.1, Revelation will enable developers to set a few properties on a system environment window (to be defined at the present time) that will:

  1. Set the background colour of the user selected cell
  2. Set the style of the cell border (lined, dotted, etc.)
  3. Set the cell border width in pixels

Whilst this can be set to ripple throughout your application, it will also respect the style defined within the form for any one edit table. In Mike’s example, I saw a new edit table with selected cell with a yellow background and blue medium solid cell border. However, the old style was used for the Table Builder showing a yellow background, dotted small border and grey row.

This approach not only delivers on the request, but it also leaves developers in control to set colours and styles to suit their application and users.

>OIPI vs OIPI.net


Following the commercial release of version 9.0 we have had a few support contacts with regards to legacy OIPI reports being run under OIPI.NET.

In short, OIPI.NET is a brand new print engine with some really nice new features that is built using some .NET based components from a third party. As such, there is no guarantee that reports built using OIPI will correctly port across into OIPI.NET without some manual manipulation.

Issues that we have seen thus far include report rendering issues – basically rows appear in slightly different places on the page compared to the original OIPI versions and in some cases the right most column can be lost from the report. The rendering issues also affect report export options. For example exporting to HTML can result in a loss of grid lines and other graphics. Revelation is also currently looking into reports of memory not being freed up in some instances.

The supporting technology changed in the last 6 years or so and that is why Revelation has maintained support for the original OIPI. In addition, it should be noted that Revelation remains fully committed to the success of applications built in OpenInsight and support for them going forward. Revelation will, of course, continue to fix issues that they are able to, as they are found and reported on the bug tracker database. Just one recent example is the TEXTBOX method fix in OIPI.NET.

I therefore advise caution when upgrading an existing application that makes use of OIPI for reporting. Please check your reports and then either make adjustments to the report, rebuild the report within OIPI.NET or revert back to using the old OIPI by making a change to the CFG_OIPI record in SYSENV:

  • VSPRINTER will run the old OIPI print engine.
  • VSPRINTER2 will run the new OIPI.NET print engine.

My new examples application has three reports written from scratch using OIPI.NET and they run very well and look good. OIPI.NET addresses issues that some of you had reported in OIPI. For example, correctly shading polygons, enhanced Unicode support, etc. Personally, I like OIPI.NET very much.