Did You Know – ClientSetup

That you can push the OpenInsight ClientSetup out to each workstation on the network.

Each workstation that accesses an OpenInsight application requires several libraries and supporting MSI packages to be installed.  Revelation have published a new technical article that presents several methods to prepare new workstations using the ClientSetup.exe program provided in the OpenInsight directory.

OpenInsight should be installed and shared from a network folder before following the guidelines listed.  If you have not already installed OpenInsight please refer to the installation instructions and then return here to setup additional workstations.

Please Click here to learn more.

Cheat Sheet for HTML coders using O4W

Whilst the wizards in O4W can help developers and power users to build some very nice online database driven applications in super quick time and without the need to write, debug and maintain Web2.0 code, it is no surprise that the true power of O4W is held within O4W’s extensive API.  However, whilst most OpenInsight and ARev developers take to building web pages using the API like a duck takes to water, HTML coders with only a little (or no) BASIC+ knowledge might flounder and find themselves on a shallow, but still unwanted, learning curve.

It is for this reason that Bryan has put together a very, VERY, useful cheat sheet to help developers with HTML knowledge to quickly and efficiently apply that knowledge to building O4W pages using the API.  The cheat sheet is split into three key sections with each showing the HTML tag, attribute, style, etc. and the corresponding O4W API attribute (I hope that I am using the correct terminology here, but someone will correct me if not).  The three sections include:

1. A non-exhaustive list of the HTML generated by O4W.
2. A non-exhaustive list of the attributes and styles that O4W generates.
3. A variety of HTML5 compliant APIs used to support both mobile and newer (HTML5) browsers.

O4W API calls generate HTML in addition to javascript, and occasionally it is useful to know which O4W call generates which HTML.  For example, when searching the internet for a particular solution to a problem, the results will usually be displayed as “regular” HTML; to convert that information into useable O4W calls, it is important to know which O4W calls will return the desired HTML.  This cheat sheet is therefore especially useful when used with the main O4W Reference Guide which documents all of the O4W API calls.  If you are familiar with HTML, then you can look-up the HTML in the left column of the table and then the sheet will give you the corresponding O4W API call to use in the right hand side column.  Armed with this information, it is then a simply task of checking the O4W Reference Guide for more detailed information about using the O4W API call.

As Bryan says, “It’s likely that at some time you’ve found yourself working in O4W, and wondered how to accomplish a specific task (like changing the borders on a table, or generating pre-formatted text).  You probably turned to Google (or your favorite other search engine) (but most likely Google) and found the answer in a few seconds – but the answer told you what HTML you need to use to generate your desired results.  How do you translate that HTML back into O4W API calls?”.  It is this cheat sheet that directly addresses this need.

Did you know . . . (BRW)

… that the new OpenInsight Banded Report Writer (BRW) in OpenInsight 9.3 has a command line interface that you can use to launch your banded reports or perform other BRW functions?

To start up the Banded Report Designer, you can do the following:

CALL RTI_BRWSUPPORT("LAUNCH")

Once you have your report(s) defined, you can generate them programmatically using the following:

CALL RTI_BRW_GENERATEREPORT(rptFile, rptName, outputName, rptType, overrideListID, rptDetails, bUseGUI)

where rptFile is the name of the report group you saved the desired report(s) into and rptName is the name of the specific report to run (or “*” to run all the reports in the group). You may also specify a semicolon-delimited list of report names if desired.

OutputName is the path and name of the file to save the output to (if producing a PDF, HTM, etc. document) – leave this blank to generate printed output.

rptType is the type of output to generate, and can be PDF, TIFF, HTML, TEXT, XLS, or XLSX (or PRINT to generate printed output, but that isn’t really needed if you leave outputName blank).

overrideListID is the ID of a saved list that contains the record keys you want this report generation to use. If there is no overrideListID specified, but there is an active select list when RTI_BRW_GENERATEREPORT is called, then the active list will be used instead.

rptDetails is only used when the rptType is PDF – if desired, you can specify in rptDetails the access permissions for the PDF, and the password(s) for PDF access.

bUseGUI is a flag that indicates whether you want report generation to occur with a GUI (set bUseGUI to “1″) or without a GUI, i.e., silently (set bUseGUI to “0″). Note that if the output is going to the printer, you can also set bUseGUI to “2″ – in this case, you’ll get a full print preview window, instead of just a printer control window as you would if bUseGUI is “1″. Note that the default if bUseGUI is not specified is “0″ (no GUI).

You can also call, during SET_PRINTER, the LOADREPORT call; this will “embed” generated BRW output into OIPI output (this is only available when using VSPRINTER2, aka OIPI.NET). You’ll pass in to the SET_PRINTER call the name of the report group, the name of the report to include (“*” for all in the group, or a semicolon-delimited list), the overrideListName, and a flag (0/1) to indicate whether the BRW report is appended to the current output (1) or replaces the current output (0).

Note that in both cases (LOADREPORT in OIPI.NET, or RTI_BRW_GENERATEREPORT) you can if desired pass in a full report definition (which is just an XML string) in the “report group” parameter. In this way, you can actually access the report definition and modify it, or create one entirely programmatically.

If this is something you wish to do, you can use the following to read an existing report definition:

rptdef = RTI_BRWSUPPORT("READ", reportGroupName, bLockFlag)

where reportGroupName is the name of the report group, and bLockFlag is a flag to indicate whether the record should be locked (1) or left unlocked (0).

RTI_BRWSUPPORT is a handy function with a few different actions. We’ve already discussed LAUNCH and READ; you can also call it with the following actions:

DISPLAY: pass in the report group name and specific report name (in parameters 2 and 3) and the report will be displayed via OIPI.NET;

 

Article first published in the Revelation Software January 2011 newsletter and on www.revelation.com

You want to do WHAT with a Popup?

The guys at Sprezzatura recently found it necessary to colour individual rows in a popup.  The example used as a proof of concept was to create a Male, Female and Other popup with the rows shaded as Blue, Pink and White.  This could be very useful to many of us in our applications and for this reason the guys have created a new blog article which includes full details and example code.

Please head over to the Sprezzatura blog for the full article.

As many of you are now creating blogs for your own business, I will be grateful if you could both email me links to your blogs and also email me if you also have something useful, like the above posting, and that you would like to share with the Revelation community. I will then gladly link to it from my blog and mention it in the RevSoft News Bulletin.

OpenInsight 9.x New Features for End-Users

My time last week learning about the new features in OpenInsight 9.3 and the plans for version 10 and onwards was motivational to say the least.  As the team pile more and more functionality into the version 9.x releases for both end-users and developers, it pains me to have discussions with people still running version 8.0.8 (and older) and who are missing out on all of the good things in 9.x.  However, I understand and respect the reasons for continuing to use these older versions.  Reasons which, all too often, revolve around the annual license fees and the upgrade process itself.

The later is something that is not too difficult, but I appreciate that it does involve some work in applying the upgrades and then QA testing before creating and releasing the upgrade.  Stepping up from 7.x to 9.x can involve some form issues, but SRP has a nice utility to assist with that issue.  I’ve personally kept my OpenInsight system up to date with the betas and subsequent commercial releases and my applications have upgraded without any issues.  That said, my contact manager (my main application) was written initially in version 9.0, so the upgrade path through the 9’s has been flawless and issue free.

Anyway, the question of justifying the annual license fee is the topic of this posting.  It goes without saying that end-users like a one time license purchase and then the option to purchase upgrades as and when, but that business model is now behind us.  The OpenInsight 9.x licensing model enables Revelation to continue to invest in the product suite, develop new features as you need them and to plan future development.  At the same time, it enables you (our WORKS subscribers) to, amongst other things, have the freedom to maintain your deployed systems without the overhead of buying upgrades from Revelation for each client every time you want to upgrade them.  At the very least this would invoke extra administration for everyone and worse still it might result in you having to support multiple versions of OpenInsight where some users upgrade and others do not.

So, to help customers with their decision to upgrade, Revelation has packed the 9.x releases full of brand new technology and new features.  Along with a myriad of fixes, these new features go a long way to enhancing the user experience and empower users to do more things and more easily.  It is a number of these new features and enhancements that I have pulled together into my updated Summary of the Benefits to End-Users in the OpenInsight 9.x Series white paper.  Touching on the more salient points that are of most interest to end-users, this document is designed to offer Revelation VARs with a bulleted list from which they can pick the golden nuggets that will appeal most to their end-users and then the VAR can expand on those points when discussing, negotiating or marketing the upgrade to the wonderful world of OpenInsight version 9.x.

The white paper will not be applicable to new customers and for that reason I will not be posting it online for download anywhere.  So, drop me a line and I’ll email you a complimentary copy in .pdf format.

Running OpenInsight on Citrix

People often ask me about the recommended configuration for OpenInsight running on Citrix systems and Revelation now have a useful configuration recommendation article available from the main Knowledge Base.  It is available by clicking here.

For those of you that I have forwarded information to over the last couple of years, here are some additional notes.  The general recommendation is still the same but Jared has informed me that you are not prevented from having different versions of the application.

If this is something that you need, then you simply create and use different shares for your application.  Let’s say you have a common set of database files in \\server\datafiles\compdata.  You could have an OpenInsight application in \\server\oi8\oinsight.exe that attached to \\server\datafiles\compdata.  In addition to this application, you could install OpenInsight in another location like \\server\oi9\oinsight.exe - making sure that you have the right number of licenses and don’t simply duplicate the licenses from the first system.  As long as the \datafiles, \oi8, and \oi9 paths all had REVPARAM files appropriate for the server machine then both versions should be able to share the same application.

O4W – Did you know?

Did You Know, that within O4W, you have the option to turn on dynamic reporting?

Located on the Forms/Reports tab in the O4W Configuration module, the options enable O4W developers to specify a number of O4W Form and Report-specific choices.

Dynamic Reports
If selected, “dynamic” reports can be automatically generated from R/List statements, which are specified within the URL. For example:

<a href="http:///oecgi3.exe/O4W_RUN_REPORT?OIREPORT=http://<yoursite>/oecgi3.exe/O4W_RUN_REPORT?OIREPORT=<reportstatement>

In the above example  <yoursite> is the full path to your O4W directory, and <reportstatement> is the full R/List-type statement that you wish to turn into an O4W Report.

For example, you may specify:

<a href="http:///oecgi3.exe/O4W_RUN_REPORT?OIREPORT=LIST">http://<yoursite>/oecgi3.exe/O4W_RUN_REPORT?OIREPORT=LIST MYTABLE WITH SOMEFIELD=”1” AND WITH OTHERFIELD=”2” SOMEFIELD1 SOMEFIELD2 TOTAL SOMEFIELD3

Dynamic Forms
“Dynamic” forms can be automatically generated by specifying the name of an existing OpenInsight form.  This is achieved by specifying the
URL as shown below:

<a href="http:///oecgi3.exe/O4W_RUN_FORM?OIFORM=http://<yoursite>/oecgi3.exe/O4W_RUN_FORM?OIFORM=<formname>

In this example, <yoursite> is the full path to your O4W directory, and <formname> is the name of an existing OpenInsight form.

If dynamic forms and reports are allowed, you may specify the permissions level needed to execute the dynamic form and report, and an O4W Form and O4W Report to use as the “template” for the dynamic form and report – the specific content of the O4W Form and O4W Report will be removed, while the menu, colour, html template, etc. will be extracted for use in the dynamic output.

In order to provide the most responsive performance possible, O4W allows you to use multiple engines to generate the O4W Form.  Each tab of the form can be “rendered” by a separate engine, allowing even very complex forms to display quickly.  You can specify the number of engines O4W should use for form generation; specify “0” for a single engine (which will generate all the tabs before returning the result to the browser), or 1 or more for asynchronous rendering.

OI 9.2.1 – Source Code Management Video

Mike has just release a new video for those of you who have been asking about the Source Code Manager in OpenInsight 9.2.1. Mike takes a look at turning on the source code manager, working with a program at various stages, setting versions and also at using the module facility and how that hooks into the RDK for easier RDK upgrades.

The video is well worth a look if you are an OpenInsight developer and it can be found by clicking here.

OI QSG – The Grande Finale

OK – So I was not done with the OpenInsight Quick Start Guide Video Series. As a few of you have rightly pointed out, I hadn’t done anything with the table on the Consultations tab on the Patient Entry window. Well, that just happened to leave a nice topic for a finale, encore, or whatever.

The 24th lesson (could this now be ‘learn OpenInsight in 24 hours’) is a feature length lesson in which we look at creating the facility to capture consultations (appointments), hook them up to the Patient window and we create a report for our hypothetical receptionists and doctors to see appointments for any given day.

In this final video (before I look at O4W), the lesson will pretty much summarise the whole series by working with the Table Builder, Forms Designer, Indexes, User Interface Workspace, Scripts and the Report Builder.

I hope that you find the series useful and that this last lesson puts the cherry on the cake.

O4W ‘Run First’ Option

Did you know, that you can enhance an O4W Report with the “Run First” option?

The O4W Report tool, in addition to all the flexibility it normally provides the user when generating a report, also allows you to specify a statement to “run first” before any other sort/selection is performed. This can be any R/List command that generates an active list, for example the report designer could pre-select data for particular users, or a particular month, or activate a previously saved list, before the O4W Report runs any user-entered selection criteria. READ ON.

Article first published in the January 2011 edition of the Revelation Software Newsletter.