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.

1

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:

3.png

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.

4

 

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.

6

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.

7

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.

8

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.

Advertisements

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


oi10tab1
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.

 

 

TRACKINGSIZE


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)

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

RETURN 0