One Evening = One Application


I was recently asked by someone looking at using OpenInsight for the first time, “How quickly can I really build a small system in OpenInsight 10?”.  Naturally, being a salesperson, the answer was “Very quickly and you’ll be surprised just how quickly.”

This evening I had the opportunity to put this to the test.

As many of my readers will know, I am some months into building a large system that I hope to take to market very soon.  This system uses authorisation keys to set (and update) the user count and the expiry date in the system.  It is nice feature in the application, but it is not overly clever.  However, I find myself having to manually create the authorisation keys from time to time and this was becoming tedious.

I therefore decided to build myself a small application in OpenInsight 10 to help me to generate the authorisation keys and then to keep a history of who has had keys, when, with how many users, etc.

Whilst I did not time this mini- project, all of the following has been achieved by a junior application developer (me) in one evening.  That includes defining the application, building the three data tables, the four forms and all of the popups, messages, etc.  It also involved writing two commuter modules to support the Customers and Key Generation forms.

As is usual for my systems, the application operates from a main MDI Frame window, as shown below.  Granted, I need to tidy a few things up (like the menus), but remember this is an example of what can be achieved in a few short hours and by a junior.

The MDI Frame is used to display all of the application’s windows and these are launched from the three buttons on the toolbar.  The fourth button being the Exit button, which closes down everything.  All of these buttons are operated by CLICK quick-events.  i.e. I did not have to write any code to get anything working in this form.  In fact, it does not even have a commuter module defined for the window.

You could say that the MDI Frame window is a NO CODE form, but that is a private joke which anyone that follows the Google Pick discussion forum will understand ;).

KeyGen-1

The next form is the Customers form, which enables me to capture some basic contact information for my customers.  At the bottom of the screen is a table which uses some symbolic fields, a relational data table and a relational index to display all of the authorisation key records that are linked to the Customer.  This enables me to see when  keys have been generated, the user count and the expiry date for that entry.  It will build into a history of the license over time.

Again, I needed to write very little code to operate this form.  The code is pretty much limited to a Changed and a Clear event to set the toolbar buttons from disabled to enabled (and vice versa), Click events for the Cut, Copy and Paste buttons and a Click event for the Email Address label.  So very little code and what code there is in the commuter module is very basic code.  To be honest, most of the code was pulled in from my commuter module template, which already had the code for the Cut, Copy and Paste buttons and to enable and disable the Save, Clear and Delete buttons accordingly.

KeyGen-3

The Customer ID label will, when clicked, display a standard record lookup window and when the Email Address label is clicked the user’s email client will launch and the system drops in the email address automatically.  Otherwise the buttons all drive the system and the combo boxes are all populated from the System Codes data table.

KeyGen-4The System Codes window is pretty straight forward with (not including the toolbar) only two key controls which use just three dictionary items (fields) in the database.

“Again, this is a no code form where I do not even have a commuter module defined.”

The combo box is populated using the Auto-fill feature in OpenInsight, which means that the pick list will always be up to date as new code categories are added.

The user then simply adds a new code category (COUNTIES in the example) and then in the table, they enter a MultiValued list of code and descriptions.   As soon as the record is saved, those new descriptions are available to the users in the Customer’s data entry form.

KeyGen-2

The last and most complex window is the Authorisation Key Generator window.

The form itself is not at all complicated and it was very easy to build, but the commuter module behind the form took some time for me to build.

The form uses my usual quick event to launch the Popup (record lookup window) and this in turn reads (displays) the record in the form.  A similar popup is used to select the Licensee’s record ID and to write that to the appropriate edit line.  When the Licensee’s ID is chosen the Licensee’s name is displayed.  This is a calculated field (a symbolic) which brings together the customer’s First Name and Last Name from the Customer’s data table.

KGImage-5The system has been designed to cater for 1 to 9,999 users.  A message will display if the user tries to enter 10,000 or more users.  Again, the message (as shown) is created without any code and it is called using only a few very short lines of code.  The code simply checks for the number of users and then it makes a call to display the saved message if the user count is over 9,999. 

The calendar button launches a standard OpenInsight 10 calendar, from which a date can be selected and this is written to the Expiry Date edit line.  The buttons on the toolbar are all Quick Events.

Once the User Count and Expiry Date fields have been completed, the Key button on the toolbar can be clicked and this will format the authorisation key using certain random  characters and formatted with hyphens.  The authorisation key is truly random, with a unique key being generated every time the key button is pressed, even when the user count and expiry date does not change.

Anyway, it is now getting late and I’ll leave the following items for tomorrow evening:

  1. I need to configure all of the menus.  The system is run by the buttons at the moment.
  2. I need to make sure that an expiry date is a date in the future.

It will then be completed and ready for use.  Not too much left to do then, a nice little authorisation key generation application done and a good evenings work.

All thanks to OpenInsight 10 and how easy the tool set makes it
to build systems like this 🙂

Elkie catches up with Mike


1P7A8552

Following our recent announcement of the release of OpenInsight 10.0.7, Elkie Holland from Prospectus IT Recruitment recently caught up with Mike Ruane to talk about this new release.

The new version includes many customer requested features and enhancements for both OpenInsight developers and MultiValue developers more widely.

You can read Elkie’s report of the catch up at https://www.prospectus.co.uk/blog/2019/09/catch-up-with-mike-ruane-and-all-things-revelation

 

 

 

OpenInsight 10.0.7 now available.


didyouknowoi10

As many of you will know, I have been internally testing OpenInsight 10.0.7 for the last week or so and I have been really pleased with the new version.

With more and more people now actively working with OI 10, this release includes a lot of customer requested fixes and enhancements.

It goes without saying that OpenInsight 10 has been a massive undertaking with the ‘whole’ product having been reviewed, modernised and made so (Ohh sooo) much easier to use.  The benefits of using OI10 over OI9 and 8 are way too many to even consider touching on here but I believe that the product is now at a point when all OpenInsight developers should be considering running their applications through the conversion tool.

If you are a current OpenInsight WORKS subscriber, you can get access to both the 10.0.7 upgrade and full install from the private WORKS area on www.revelation.com.

For now, I’m off to try a brand new module in O4W which Bryan worked on for a project that I have been working on for a few months.  My development learning curve continues at a pace 🙂

Sorry


PropertyGrid2Someone asked me a couple of days ago, why I have been so quiet on the blog, etc.  The truth is, that I have been heads down for the last few months building a new system for a client.

This system is taking all of my time (including a lot of my personal time) and finding time to update the blog has come second place.  No excuses, that is just the way that it is.  So mixed with OI development, photography gigs and sleep, there has been little time for anything else.

That said the project is coming along well and I continue to be amazed at what a junior application developer can achieve with OpenInsight 10.  Yes, I continue to make mistakes but I continue along the learning curve and things are definitely getting easier and quicker.

A fun week playing with the Internal 10.0.7 pre-release.

Just this week, I was given access to the internal 10.0.7 pre-release.  The subsequent testing had me find a small bug and yes, I did do something unexpected, and yes, I am that monkey and if you give me a nice shiny new gun, well, I ‘will’ shoot myself.  Anyway, this has given me with a few minutes to take a step back and catch up with the blog and other things.

However, despite the bug (which has already been diagnosed and fixed) 10.0.7 looks to be another big step forward and it is definitely getting to the point (in my opinion, it’s there now) where existing OpenInsight , ARev and MV developers more widely should be taking a close look at using OI10 modernise their development and their systems.

OpenInsight 10.0.6 is now available


didyouknowoi10As many of your will know, I have been a avid supported of OpenInsight 10, working with the alpha, beta and now every release since it was released to the world.

With every new release I find something that makes my life as a developer easier, faster and more pleasurable.  Only last week, I stumbled on the fact that I no longer need my VScroll code to make tab controls work, you now only need the click event and OI10 take care of the rest.  Yet another example of more of my code that I can remove in place of professionally written and optimised code and a time saver for the future when adding new tab controls to my forms.

So, what is new in OpenInsight 10.0.6, which has just been released.

Presentation Server

General

  • Optimised page swap rendering
  • Implemented PAGESWAPRENDERMODE property for paging components
  • Implemented REPAINT method
  • Added Repaint parameter to the INVALIDATE method
  • Removed “inherited event” processing
  • Added RDW_FRAME when setting REDRAW back to TRUE$

DATETIME object

  • Implemented Relative time specifiers for VALUE-based properties

WINDOW object

  • Implemented READPREV method

O4W

General

  • Improved performance by reducing redundant output (for duplicate events and classes)

O4WQUALIFYEVENT

  • Added new event “classlink” for optimization (used for example with a whole table of links or buttons so that there’s only a single function that gets called to act on the click, based on a class name )

O4W Form Wizard

  • Changed to use new optimised classclick event instead of individual qualifyevents on icon buttons
  • Added ability to specify foreground and background colours on search results page

O4W Report Wizard

  • Changed to use new optimised classclick event instead of individual qualifyevents when called as multi-select popup

Lock Manager (OI Console)

  • Changed to use new classclick event

Banded Report Writer (BRW)

  • Added support for SYSDICT items.  Example code added to supplied RTI_BRW_SUPPORT example routine.

Miscellaneous

RTI_CHAIN_SELECT

  • New routine to optimise multiple sequential SELECT statements, when issued either to local OI system or back-end BFS.
  • Subroutine accepts a series of SELECT statements (@fm delimited), determines if local or server selects, runs the statements as a block, and returns the final set of keys as an active select list.
  • Currently implemented for OI, D3, QM hosts.

Click HERE for a copy of the OpenInsight 10.0.6 ChangeLog.

 

RevUK and Sprezzatura email down.


mail_server_errorPlease be advised that the email system for both Revelation Software UK and Sprezzatura is down today – 14th March 2019.

We understand that email sent to us is ‘not’ bouncing back to the sender and therefore people might not be aware that there is an issue.

The issue is with our third party email provider and a support incident has been raised.  However, at the time of writing, we do not have any details about the cause of the issue nor know when the issue will be resolved.

We will all respond to email as soon as the system is back up and running and we are receiving email again.

If you need us urgently please contact us on the usual office telephone numbers which are available from www.revsoft.co.uk and www.sprezzatura.com.

In the meantime, we apologise for any inconvenience caused.

Lots of data to capture in a single form? OpenInsight 10 has the prefect solution.


PropertyGrid1I occasionally have people ask me about user interface design from an end user’s point of view and mostly this is when a developer is tasked with capturing a very large amount of data, needing lots of controls, in one logical place.

Often, it is possible to break up the required data into bite sized chunks, or to categorise it somehow and then present their data controls as a smaller subset on two or more forms.  Sometimes, probably more often than not, it makes sense to break up the form using the tab control and display these subsets of data controls over multiple pages.  This is something that I have done a lot in my demo applications.

However, I am told that this is not always possible and I have seen data entry forms with hundreds of controls, split over countless tabs.  I recently heard of one OpenInsight based system where a control limit had been reached, forcing a rethink of how the data was to be presented to the end users.

Now, I am currently working on a ‘real world’ application that also demands that, on several of the data entry forms, I need to be able to display and capture hundreds of data fields.  For the form that I am currently working on, this means nearly 400 hundred data items and this translates to well over double that number of controls to be maintained on the form.  AND, I can find no logical way to split these controls over multiple forms 😦

A form with this number of controls means that I had a massive tab control and a form running over 20 or more pages.  From a developer’s point of view, this results in a very cumbersome form to manage and maintain at design time.  For example, how would I easily add in new data prompts without having to spend a large amount of time moving controls around to make the new items fit my already crowded forms?   Worse still, it resulted in a very difficult to navigate form for my users.  Yes, they could probably learn where everything is over time, but in the interests of providing my users with an intuitive display from day one and a far easier to navigate user interface, I had to find another method.

So, following a quick prompt from Carl, I took a look at the brand new Property Grid control in OpenInsight 10.  This is not yet data aware (and I’m not sure of any plans to make it data aware), so there is a code to be written behind the scenes for my use of the control, but it was definitely the perfect solution.

So what did I build to get over this large number of controls issue?

PropertyGrid2

As you will see in the data entry form above, I have managed to reduce the tab count to just 12 tabs.  Although this is still quite a lot, they make sense because most of these will be displaying related data from other data tables.  For example, a list of actions to be undertaken or that have been completed with dates, status and notes, or viewing details.  These will be largely edit tables, one on each tab.

The main tab reduction was achieved through the use of the Property Grid, displayed on the right of the form.  When the user is on the Summary tab (shortly to be renamed), the property grid maintains a few hundred property details that were originally split over numerous tabs.  This data is now displayed in a easily navigable, collapsible, categorised list, enabling the user to show and hide data as required.

When designing the Property Grid, the OpenInsight developer is presented with 29 pre-defined control options that are embedded in the new control.  Things like Dialog, Static and colour pickers, right through to combo boxes, file pickers and more.  The user’s choice is then displayed in the grid and it is pretty easy to them pick up those values and save them to the database.  It is also super quick and easy to add in new data items and to have them display under the correct category.

The Property Grid control is fully documented in the ‘OpenInsight 10 Presentation Server Reference Manual’, but writing data to a cell in the grid is just one line of code.  In the example below, valPropertyStatus contains the data to be written and “Property Status” is simply the name that you have defined in the Property Grid row when you built out the various rows.  It really is that easy, no messing around trying to work out in code which cell or row you are in, you simply use an ‘English’ name.

 Call Set_Property_Only ( CtrlEntID, "VALUE", valPropertyStatus, "Property Status" )

Now, as I might have mentioned earlier, the Property Grid is not yet data aware, so you will need to get these data changes and write them to the data record yourself.

However, I have taken a slightly different approach.  I am not a professional OpenInsight application developer, so I in no way suggest that this method is right and proper but it works for me.

As shown in the image below, I wanted to have collector windows for ‘each’ of the data items in the grid.  This enables me to provide my users with a consistent and easy to navigate solution.  It enables me to present my users with all manner of data controls in easily built and maintained collector (dialog) windows.  In the example below, when the user clicks on the Vendor cell (a button displays), the user is presented with a collector window with, not only the vendor’s name, but also their contact information.  This includes the email address and if the user clicks the blue text, OpenInsight will open up the user’s default email client and drop in the vendor’s email address.

PropertyGrid3

You will notice that the orange Record ID box displays the Record ID.  This will be made invisible for the beta, but it is displayed for development purposes at the moment.  This Record ID is passed to the collector window from the calling window and the record is automatically read and displayed for editing.  When the user has made their changes, the data is immediately written to the record.

When the data is saved and the collector window is closed, the Property Grid is updated to display the new value, or values.  In the case of a collector window with multiple data items, I have chosen the best piece of data to display.  In the example above, this is the Vendor’s name.  In some other instances, I have used three dots (. . .) to indicate that there is data to be viewed.  This solution is used when no single data value works.

A nice, easy and good looking solution.  

Now, those of you that are professional developers and observant, will have noticed a flaw in my design.  If I am passing in a record ID, what is to stop the user from saving a value from the Property Grid without a valid Property Record?  This could quickly result in useless data – property characteristic details without a property address and other meaningful data to readily identify the property,

This issue is addressed by simply checking for a valid record on file when the Property Grid is accessed. If there is no record yet saved to file or it does not meet my requirements of having a valid address, access to the Property Grid is blocked, a message is displayed and the message and collector window closes when the user clicks the message’s OK button.  i.e. the user cannot add data to the grid without a valid record being already saved to disk.

PropertyGrid4

Yes, the method that I am using is a little more complicated than just allowing the user to change the data in the Property Grid and have that data saved when the main save button is pressed.  And, I’ll probably allow that as an option further down the line.  However, I’m pretty pleased with this solution and it is definitely making it easier to develop and use my application.

Oh, and for those of you that think creating and maintaining many collector windows is long winded and time consuming, this is actually pretty quick and easy.  I simply:

  1. Use a template window – So, Open and Save As.
  2. Use a template Commuter Module which prompts me for certain bits of information which are dropped into the code automatically and then this is compiled and saved.
  3. Test run the window and add any additional event code that might be needed.

I am not saying that this is the right, recommended or perfect solution but if you would like to see this in more detail please comment below and I’ll look to put a video together with a look at the Property Grid working and the code used behind the forms.