Renaming a Table

didyouknowoiSo, I build most of my applications without much planning and preparation.  Yeah, yeah, I know P*** poor planning = P*** poor performance, but I am not a professional and I don’t pretend to be, I just quickly knock systems together for a hobby, as a learning process and also for demo purposes.

In the the following case, I had a table called MP_OPPORTUNITIES, named thus for historical reasons and so that I could easily copy and paste code from another application into this one.  However, the application that I am working on ‘might’ make it into OpenInsight 10, or I might release it on a case by case basis to OI WORKS developers, I’ve not decided yet, and for that reason I’d like to have table names and form names that make some sense.

Anyway, the form would be better named MP_ORDER_ENTRY and therefore the corresponding data table would also benefit from being called MP_ORDERS (following my naming convention).  So, I dropped into the Database Manager, changed the table name and was prompted with the Impact Analysis report.  I noted the items and duly renamed the table.

Problem 1 – The form now opens as read only and I cannot change the data bindings, as I had expected I would :(.

Plan B: Restore from backup and this time I’ll clear out all of the data bindings in the form, save it and then rename the table.

Problem 2 – OI will now not save the form because I appear to have a rogue data binding and OI cannot find column ” “.  I checked all of the data bindings and even removed a couple of edit tables, alas no joy!!

A quick call to support and once again the guys put me on the right track.
It is always easier to do things the right way, instead of blindly ploughing into self made problems.

So, if you have a badly named table, this is the best way that ‘I’ have found to put your system right:

  • Design the database and system properly from the outset ;-).

    This should be a given,  but if you are like me, you’ll need to do the following:

  1. Firstly take a good backup of your system, right before you try this and not the day before, like me (will I ever learn?).
  2. Open the Database Manager, select the table that you wish to rename and rename it to your new table name.


  3. When you rename the table, OpenInsight will conveniently run an Impact Analysis check on the system and report entities that you might (will) need to look at following the renaming of the table.  OpenInsight does not (at this stage in the OpenInsight 10 development) rename all of the values throughout the system for you.  That’s currently a manual process.

    In my case, this means looking at two forms.  For a system that might be a little older, it gets a little more difficult and you might have popups, reports and other entities to consider.  It might even be worth sticking with your badly named table.  After all, the only time that end users are likely to see the table name is if you have exposed any report writing tools to your users.

    I should also point out that, I have previously chosen bad table names and I have renamed them before creating any forms, popups, reports, etc. against the data tables.  Those rename perfectly and with no extra worries or work involved.

  4.  So, we now have our renamed table and list of problem forms.  Lets sort those out by opening a record (Ctrl+R, or Open Record), selecting SYSREPOSWINS as the Table Name and locating our required Record/s.  In my case it is the form called SYPHERSPOS**MP_OPPORTUNITY_ENTRY (as shown below).


  5. This will open up the record in the OpenInsight Integrated Development Environment (IDE) using the appropriate tool, the System Editor ++ in this instance.  For the uninitiated (like me), this is a daunting screen and one in which (I think) someone with only a little knowledge can do a lot of damage – so be careful and get advice if you don’t know what you are doing.


  6. Thankfully, OpenInsight’s ‘Find and Replace’ feature comes to the rescue.  From the Search menu, we select Replace and we are prompted with the dialogue window shown below.  Simply enter the value that we want to search for in the ‘Find what’ prompt (our old table name in this instance) and the new new table name in the ‘Replace with’ prompt.  All very straight forward.


    OpenInsight will then trawl through the record and let you know how many instances of the value have been found.  Click Replace All (as above) and the System Editor makes the changes and reports the replacements accordingly.

  7. So, we now have a renamed table and a form with an old name and new data bindings.  We can now launch and run the form and it’ll work just fine, pulling data from the newly named table.  However, one last step is needed to put our system right.

    We open the MP_OPPORTUNITY_ENTRY form in the Forms Designer and simply select ‘Save As’ from the File menu and save the form with the new name – MP_ORDERS.


    This will leave you with both our new MP_ORDERS form and the old MP_OPPORTUNITIES form.  Open the old form and select Delete from the File menu and you are done.

Of course, all of this hard work could have been avoided if I’d spent a few minutes properly planning my system.  However, it is nice to know that OpenInsight and the guys at Revelation Software still have my back and if I get myself into, they can help me to get out of that mess again.

Note to self – It really is time to get some proper training 😉

Thank you to Andrew and Bob for helping through this.





10 + 10 = Ouch!!

So, I had some computer issues yesterday (not OpenInsight based I am pleased to confirm) but the end result saw me blowing my machine away and opting for a complete factory reset.  This is usually a pretty painful task, but ‘boy’, did I not know the half of it.  This posting is therefore a reminder for me and also to enable all OpenInsight installers to better prepare for their OpenInsight installations.

With my machine sitting with a newly installed copy of Windows 10, I updated my Internet Security and immediately dived into installing OpenInsight 10 on my machine – well it is the most important piece of software on my box and an application that runs my working life.  Well, I say install but I actually did what I have done a thousand times before and simply copied the RevSoft folder from my backup drive onto my new Windows 10 installation and launched the ClientInstall.exe to install those all important files that OI10 needs to operate properly. 5

Before doing anything with OpenInsight and as per the normal OpenInsight installation documentation, I took the added precaution and checked to make sure that I had the .NET Framework 3.5 and 4.6 installed on my machine.

All was good with both Frameworks displayed in the “Turn Windows features on or off” window.

I therefore ‘thought’ that I was good to go and copied over my backed up RevSoft folder, then I located and launched the ClientInstall.exe file using the ‘Run As Administrator’ option.  However, half way through the install I got the following warning.


Now, I know that I don’t have the later .NET Framework installed, so I clicked ‘Yes’ to launch the Microsoft webpage.  This presented me with the .NET Framework 4.7.1 option front and centre and that seemed like a good choice – well it can’t hurt to have the latest version.

Alas, after downloading the file and running it, I was presented with a Microsoft .NET Framework Blocking Issue warning and the only option is to Close out of the installation.   2

OK, so the OI system did say that I needed 4.7, so back to the Microsoft website and towards the bottom of the page are several options including 4.7.  Naturally, I downloaded and installed that version.  Alas, the exact same Blocking result:


I knew that I’d had the earlier version installed, so I tried 4.6 but, as expected I was told that it is already installed.  Out of desperation I thought I’d try the 4.6.2  version and success, it ran through a full installation.



Jumping back into the OI ClientInstall I ran the file and crossed my fingers.  Again, the installation failed.  OI really does want 4.7 and nothing else will do.

Time to dive into the ‘More Information’ link and something that I really should have done first off.  This presented me with a long page of different things that can affect the .NET installer but towards the bottom covering just a couple of lines is a note about the .NET Framework 4.7 needing the Windows 10 Creators edition.  Checking my machine and because this is a machine that is a couple of years old, I naturally have an older version.

So, into Update and Security and I began to download the upgrades.


With the first set of upgrades installed, I ran the updates check again and the system went off to pull down the Creators Fall Edition, one heck of a long download and almost as long to install.  This process began at around 10:00 hrs this morning.  It’s now gone 16:00 hrs and the Creators Edition is finally installed.  One last update check and one last batch before a final check and we are finally up to date.


This time when I ran the ClientInstall, the system ran through as expected with no call out to Microsoft and no need to manually install the Microsoft .NET Framework 4.7, that appears to be installed as part of the update.


Somewhat relieved that all now appeared good, despite nearly a whole working day taken to run the upgrades, I launched OpenInsight 10 and my application and it is now functioning exactly as expected – PHEW!!!

So, what is the moral of this sorry tale or woe, angst and dead ends.

The Number One Rule:  Make sure that you or your client have your windows 10 machines fully upgraded BEFORE you step through the door to undertake any software installation that needs a .NET Framework and especially OpenInsight 10.

I’d have hated to have arrived on a client’s site to install their new OI10 based system, to find myself sitting there waiting for Windows 10 machines to update.  One would hope that the machines will have been installed for a while and be fully updated, but you just know that there will be people who only opened the box and turned it on that morning.

Also, be warned that if you have to blow your machine away and back to factory settings and it’s running an earlier Windows 10 release, you will have to factor in a long wait.  I guess that there can be something said for keeping mirror image backups.

So, now that I have my OpenInsight 10 working you’d think that I’m about to dive in and continue with my conversion.  Nope, I’m off to coach archery and OI10 will have to wait until a little later.

OI10 Splitter Bars – Ouch and a smile.

splitterOn the whole, my OpenInsight 10 (OI10) Beta 4 conversion has been a major success and I’m now using the application on a daily basis and working on the UI to make it cleaner using the new tools in OI10.

However, one gotcha which we should all already be aware of, is the splitter bars that were introduced in OI9.  In that version, you simply dropped the controls on the form and it did its best to resize controls (usually edit tables).  The downside for me was a flickering screen as the form constantly redrew whilst the bar was being dragged by the user.

In OI10, Carl has introduced a new ‘MOVE’ event which enables developers to very quickly and easily handle the resizing of the controls to best suit the application.  In my example, I have a form with three panels (Groupboxes) and on each panel is an editable.  The panels are then set to autosize and the following code is added to the upper and lower Splitter Bars to managed the moving of the bars as needed.  The code below is taken from the Upper Splitter bar’s MOVE event.

Declare Subroutine Set_Property

// Adjust the window's controls as the user moves the horizontal splitter bar.

   // Get the bar "thickness"
   barH = Get_Property( ctrlEntID, 'HEIGHT' )
   // Get the bar initial position
   barP = Get_Property( ctrlEntID, 'TOP', YCoord )
   // Move the bar
   Set_Property( ctrlEntID, 'TOP', YCoord )

   // How far did the bar Move 
   barM = barP - YCoord
   // Move the upper panel control
   valPanelUpper = @window:'.GRP_ALF30DAYSPLUS'
   Set_Property( valPanelUpper, 'BOTTOM', yCoord - 4 )

   // Move the lower panel control and reset the height
   valPanelLower = @Window: '.GRP_ALF30'
   Set_Property( valPanelLower, "TOP", yCoord  + barH + 4 )
   valPanelHeight = Get_Property(valPanelLower, 'HEIGHT')
   Set_Property( valPanelLower, 'HEIGHT', valPanelHeight + barM )
return 1

Disclaimer: The above code is written by me as a non professional developer.  Whilst it works, it is not optimised, does not include any error trapping and does not promote best practice.  The above code includes comments to explain what it does.

I was initially disappointed that I would have to write code to manage the splitter bars, but now that this is done I really like the way that I have control over the controls that move and that the form no longer flickers when the splitter bars are moved.

For more details about OI10 changes, please check out Carl’s OI10 Blog.


Confusion & Wisdom

This again is going to be more of a memory for me, but it will still be useful for those of you working with the OpenInsight (OI) 10 Alpha.  I’m a back to working on an application for one of our Value Added Resellers (VAR) and I’ve been trying to build a dynamic toolbar because the system is mostly operated by touch screen operators.

The current menu is three levels deep and the toolbar is limited in space.  I therefore wanted to have a double toolbar with one row of static buttons and a row below which would change depending on which top level button (menu item) is clicked.  The obvious way to achieve this is a panel with a row of buttons and a tab control.

Now the Tab Control in OI 10 is located under the Containers sub category in the Toolbox.  I therefore thought “Great, I’ll drop the buttons on the tab and all will be good.”  However, the current Tab Control has been specifically designed to operate like the current OI9 Tab Control.  This uses paging Forms and you simply drop the controls on the appropriate page, rather than the tab control.  Dropping them onto the Tab Control is actually impossible because it jumps to page one all of the time.  Nevertheless, thinking that the tab control was an intelligent container, I blindly pressed on, getting myself into a state of confusion.

Five minutes later and Carl put me right.  He explained that the current Tab Control has been written to work exactly like the current one so that people’s upgraded applications will not break – that’s the Wisdom and I really glad that Revelation are thinking about supporting existing application, rather than blindly building new controls for new applications.

All I needed to do was:

  1. Drop the tab control on my form and make it shallow so that only the buttons show.
  2. Drop the buttons (or whatever controls) onto the appropriate pages and where I need them to show on the tab control.
  3. Then the bit I was missing.  The buttons will most likely display under the tab control.  So, click on the button, right mouse click and choose ‘Bring to Front’.
  4. Finally, slide the Tab Control over the buttons to contain them – or give the appearance to contain them.
  5. Add the usual tab control code used in OI9 and you are done.

So, what about a brand new tab control that works as a container and that has pagination, or whatever?  Well, don’t hold your breath, but watch this space.

A few minutes later and I have my working dynamic toolbar.  Now I just need to add some glyph images, some code to launch the associated forms and I’m done :D.


Running two instances of OI10

OK, so this posting is more as a reminder for me going forward than anything else.  Last weekend I was working with the OI10 Alpha and I wanted to copy things from one instance of OI10 to another. However, I was blocked because I was only permitted to use one engine and it was being used by the first instance of OI.  I thought that this might have been a restriction but I reported it anyway.

It turns out that this is another setting in the new .rxi file that is used by OpenInsight when first launched.  I have a couple of .rxi files on my system, so the first challenge was to work out which one I needed to change.  This is pretty easy to work out, you just follow these rules:

  1. If the RX switch is used in the shortcut, you’ll use that .rxi file.
  2. If none is defined then OI10 will look for a .rxi file with the same name as the application that you are loading with the /AP switch.
  3. If there is no application defined using the /AP switch, then Oi10 assumes SYSPROG and it’ll use that .rxi file.

So, after a quick check, I’m using SYSPROG, or the SYSPROG.rxi file in my bin32 folder under the OI installation.

I initially guessed that my issue was the <singleInstance> entry which was set to 1, but Carl quickly put me straight and told me that heading will shortly be changed.  In the meantime, he’s told me to look at the <serverName> entry in my .rxi file.  Because I have a serverName set, I am effectively trying to use the same engine as the first instance and Oi behaves correctly and stops the session.  All I need to do is clear the entry by setting it to nothing and then OI will launch as many instances as my license count permits.

Starting OI10 is fully documented in the ‘OpenInsight 10 Presentation Server Object Model’ documentation.  This is a work in progress document that is already into 272 pages but today has been yet another reminder of the numerous options that the guys are exposing to developers when launching OpenInsight.

Consider the .rxi file as a more powerful OInsight.ini file and you won’t go far wrong.  Just don’t do what I did and blindly dive in.  Please take some time to better understand the .rxi files as noted on Carl’s OI10 blog and also in the paperwork when eventually published and released.

For now, I’ll be back into my OI10 Alpha project later today for more learning.




This one is more of a reminder to myself for when I take another look at my CRM system interface in a few weeks time but whilst working on a clients interface (a personal project), I needed to set the size of my MDIChild windows.

I’d set the option to Window’s ‘Frame’ option to ‘Thin’ and it displays just fine in test mode when the window runs on its own.  However, Windows overrides this when it is run as an MDIChild window and the frame becomes thick and the window is therefore sizeable.

I search around for a solution but needed the help of our resident OI Guru (thanks Carl) to point me in the right direction.  The cursor still displays with the arrows over the frame but I’ll look at that later.  For now, the code below (lifted straight form the OI help files) sorts me out just fine.

*/ -----------------------------------------------------------------------------
*/ 16/09/2016 - MDP
*/ Set the frame to not allow the users to change the size

    CurSize = Get_Property(@Window, "SIZE")

    MinW = CurSize<3>
    MinH = CurSize<4>
    MaxW = CurSize<3>
    MaxH = CurSize<4>

    x = Set_Property(@Window,"TRACKINGSIZE",MinW:@FM:MinH:@FM:MaxW:@FM:MaxH)

*/ -----------------------------------------------------------------------------