Category: Technical


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.

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.

After the initial release of OpenInsight 9.3 it was discovered that the original IDX_SETS routine (IDX_SETS1) no longer returns the correct results when doing indexed selections of large data sets. We are therefore suggesting that all users of OpenInsight 9.3 change their system to use the newer IDX_SETS2 routine.

IDX_SETS1 is the original OpenInsight routine and has been in the product since its inception. IDX_SETS2 is a relatively recent .NET based emulation of the functionality.  With small data sets, IDX_SETS1 seems a little faster than IDX_SETS2, but we’ve found that with large data sets, IDX_SETS1 appears to get “confused” on modern versions of Windows.

You can configure which version of IDX_SETS you use by creating or editing the record CFG_IDX_SETS in the SYSENV table. To use the new IDX_SETS, make sure field 1 of this record contains the string IDX_SETS2; to use the original, make sure field 1 contains the string IDX_SETS1.

Note:
The CFG_IDX_SETS record will control which version of IDX_SETS is used by default for everyone on the current OpenInsight system.  If instead you want to specify, for a specific user and application, which version (IDX_SETS1 or IDX_SETS2), you should create or edit the record CFG_IDX_SETS*<appid>*<username> (ie, CFG_IDX_SETS*EXAMPLES*EXAMPLEUSER); if you want to specify which version to use for everyone in an application, you should create or edit the record CFG_IDX_SETS*<appid> (ie, CFG_IDX_SETS*EXAMPLES); if you want to specify which version to use for a specific user in all applications, you should create or edit the record CFG_IDX_SETS**<username> (ie, CFG_IDX_SETS**EXAMPLEUSER)

… 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

Revelation have identified an issue in OpenInsight 9.3 that prevents scheduled and dedicated indexing processes from starting.  The problem is limited to these scheduled index processes:

  • Set_IDX function launches the dedicated indexing window but no indexing occurs.
  • Launching OEngine.exe with /I command line argument launches the dedicated indexing window but no indexing occurs.
  • The background indexing setting in the database manager that specifies the delay before indexing has no effect.

Routines that call Update_Index directly or run the dedicated indexing service as a Windows scheduled task are unaffected by this problem.

OpenInsight WORKS subscribers can gain access to the patch by logging into the WORKS area on www.revelation.com.

Revelation have just officially announced the release of OpenInsight 9.3 and the office press releases can be found on both the Us and European websites.  The European press release can be found at http://tinyurl.com/ctz85u2 and it touches on the major new features, being Data Encryption at Rest, O4W version 1.2, the brand new Banded Report Writer and the inclusion of some Extended Math Functions.  This release also sees an enhancement to the D3 connector, which now fully supports TigerLogic’s mvBase.

As Mike mentions “Our connection technology has truly made OpenInsight a versatile front-end graphical database development environment”.  With the other advancements in the technology, I am proud to be part of the Revelation team and I look forward to bringing the benefits of OpenInsight 9.3 to the wider developer community throughout 2012.

If you are a current WORKS subscriber, the OpenInsight full install and upgrade can be found in the private WORKS area.  For those of you who are not yet on WORKS, the 9.3 evaluation software will be available for you trial very very soon.

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.

Debugger_Dump

Environment Settings screen shot

Environment Settings Screen

OpenInsight 9.2.1 saw the introduction of a Debugger Intercept facility and this can be used to create a Debugger Dump file.

The debugger_dump procedure is designed to be executed from within a “debugger intercept” procedure which is triggered when the engine hits a debug condition.  The intercept can be setup by simply openning the Database Manager and chosing the Environment Settings option from the ‘Database’ menu.  On that screen the Intercept radio button can be selected (as shown in the graphiv opposite).

The debugger intercept procedure by default is called “Debugger_Replacement” and an example version is supplied with OpenInsight and you can change this to your own procedure if you wish by updating field 54 of your application’s environment record (see the ENVIRON_CONSTANTS insert) or use the dialog above.

Once in the intercept routine you can look at the contents of any variable in the broken program with the debugger_Fetch() function.   An example of how this works can be found the the debugger_dump() procedure, also supplied with OpenInsight.  This simply attempts to write out the local and global variables to a text file.

One thing to remember about working in the debugger intercept routine is that the engine is already in an error state – your code should do the minimum possible to handle the error and then return – doing lots of screen updating, displaying messages and stuff probably isn’t a good idea.   When we use this we normally write the errors out to a log or send an email and then return.

Thanks to Carl Pates (Sprezzatura) for this article.

 

And finally we reach day nine and the last of my postings taking a look at the OpenInsight 9.3 beta release highlights.  Today we will take a look at what the new release has in store for our ARev clients that are making (or planning on making) the move to ARev32.  The readme includes five modifications and they include:

  1. Case options now work correctly on selects.
  2. Environment ini files have been enhanced to allow for user environments.
  3. Selecting with parentheses in the selection criteria no longer causes the select to cancel.
  4. ARev32 and CTO configuration records have been enhanced to conform to the CFG_XXX format.
  5. An additional AREV32/CTO configuration option has been included.  Setting field 6 to “<<NONE>>” will suppress the auto-start of ARev32 in AREV32_xxx_FORM (for graphical debugging.
  6. V23 (AREV32 RUN) has also been updated to save the stack when running in graphical debugging mode.

The 9.3 beta readme includes more details about the above items and the remaining items that I have not noted above.  In addition, it also includes many of the new features, enhancements and fixes throughout the 9.x releases.  Please drop
me a line
if you would like to receive a copy of the full 9.3 beta readme file.

Just two more postings and we’ll have covered the highlights of the OpenInsight 9.3 beta release.  Today, we will turn our attention to enhancements that have been made to Basic+.

  1. The COLDROPDOWNLIST message now repaints combo controls when they are being set.
  2. EMAIL_FORMAT now allows domains that begin with numbers.
  3. The CREATE_TABLE command will no longer append the user’s name and the ‘@’ sign when created by non-system administrators.
  4. DELETE_TABLE will now remove the bang table from the database.
  5. GET_ENV now returns values above 53.
  6. An issue where any popup would not return any value if the last popup had a system error.
  7. RTI_REMOVE_INDEX has been created to remove all indexes from a table including deleting the bang table and SI.MFS.
  8. New extended math operators have been added.

The 9.3 beta readme includes more details about the above items and the remaining items that I have not noted above.  In addition, it also includes many of the new features, enhancements and fixes throughout the 9.x releases.  Please drop
me a line
if you would like to receive a copy of the full 9.3 beta readme file.

Follow

Get every new post delivered to your Inbox.

Join 67 other followers