PICED 4.12.1.0 exception error

Thanks Ashleigh, as ever some interesting reflections... however, If I'm understanding correctly from the very last sentence, you are thinking that my problems arose *because* I changed the install path from C:\Clipsal to C:\Program Files??? - the exact opposite is true - I had endless and insurmountable problems when it WAS installed under the default C:\Clipsal, and every single one of them went away when I as the end user forced the change to C:\Program files...

My experience was the exact opposite... Toolkit & CGATE were installed into C:\Program Files many months ago, and have never missed a beat. PICED was recently installed (errantly) into the default C:\Clipsal folder, and THAT caused everything not to work, and the exceptions being thrown were complaining about being unable to write to the registry, unable to access NIC's, not enough permissions to do this, that or the other... PICED (Whilst running from C:\Clipsal) would just about run (i.e. it would launch) but couldn't do just about anything that it needed to. Now that I have uninstalled it & reinstalled it into C:\Program Files, everything is hunky-dory again...

I take all of your points regarding the difficulties involved, or rather the decisions to be made in making a change... - however from reading what you said, 2 things struck me...
1) It sounds like the policy of the default install path was left unchanged for management/political reasons rather than for technical reasons? -

In my personal opinion, in general I think technical decisions should be based on the technical considerations not management/political ones.

2) If it is really as difficult to accomplish, and risks dire upset to change the default install path, then *WHY* offer the end user the option to do so in the installer? - why would you give the end user an option which it sounds like you imply would never work properly, generate loads of support headaches, and generally be a "really bad thing"...

Now it turns out that as I checked the other day I noticed that back when I installed Toolkit/CGATE etc. on this machine, I did - as I normally do - ensure
that the apps were installed to C:\Program Files and NOT to C:\Clipsal, however, months later when I installed PICED I 'forgot' to do that so it ended up in the default C:\Clipsal folder all on its own... - perhaps *that* was compounding the problems??? - that therefore begs the question: when installing other components of the same software suite, why not check first where the other components are already installed to (easily done via a quick registry lookup I'm sure), and then use *that* location as the default offering in the installer?

IMHO - and as I've said before I am *NOT* a developer, I think the overall difficulty of the migration, as you have described it is perhaps a little exaggerated? - you don't ever have to force users to reinstall everything...
Since you give end-users the option to change the path during install, clearly the option to do so *must* be a supported configuration? - your description of the issues & considerations surrounding making the change does to my mind at least, make it sound a little bit like it's being suggested this isn't so?
If, in fact, changing the path away from C:\clipsal is NOT supported, then why on earth would you give the user the option to do so, so prominently and easily? - that would make no sense...
A sensible approach would therefore be - IMO - offer the user the choice of install path during the installation of the *FIRST* piece of CBUS software going onto the machine - the default could well be left at C:\Clipsal if you like... - it's trivially easy to do a simple test to see if there is any other CBUS software already installed, or if the C:\Clipsal folder already exists etc. Thereafter, during subsequent installs of other components of the suite, have the installer lookup the install path already chosen by the user and do one of two things:
a) don't even offer the option to change it, - just install automatically into the same folder as the other components. This would be the best choice IF installation to the same folder as the other components is crucial to correct operation (which it sounds like it is?)
b) If it is acceptable for the component currently being installed to live in a different location, then offer the user the usual dialog box to change install location, but pre-load the default offering in the dialog with the value just read from the registry pointing to the install folder for the other existing components.

It seems like my experience suggests that the installation logic allowed the combination that is the worst possible scenario to come to pass - and not by the user (i.e. me) doing anything consciously - I just forgot that 9 months ago I chose one install path, and this time I forgot to change it... easily done I think when components are installed many months apart and when the installer for each component makes it trivially easy to change...

So to address your three bullet points specifically:

No. Leave the other stuff where it is, look that location up, and then apply the a/b choice I described 2 paragraphs back.

Absolutely not. and not necessary if the previous logic is applied.

Absolutely not. and not necessary if the previous logic is applied. the 'problem' simply doesn't exist..

In an *existing* installation, where other components are already present, just have the installer default to the same path. No-one is suggesting - certainly not me - that users are ever *forced* to do anything - if an end user *wants* to change the install path for the entire(already installed) suite, that is their choice, and most everyone would, I think, understand the implication of that activity - i.e. uninstalling and re-installing *all* the components of the suite - but by choice not by force...

The simple expedient of changing the default install path for the *FIRST* CBUS software component to C:\Program Files, would, over time, slowly transition the bulk of users over to that location. The simple expedient of *checking* during subsequent installs would, I think, avoid seriously broken installations by preventing components ending up in separate folders.

I think at the end of the day, that perhaps we approach thinking about this from different perspectives? - you from the developers point of view, and I from an end-user experience point of view... Without meaning to sound trite, it is my belief that software is (or should be!) written *for* the convenience of its users, rather than for the convenience of its developers.... As I said before, I'm not immune to the plight of the developer, but just because something is difficult, troublesome, awkward, inconvenient or challenging for the dev's to accomplish, is not, in itself, reason enough not to do it - if technically it is the 'correct' thing to do, or aesthetically it is the 'better' thing to do in terms of user experience...

Obviously, and as ever, all just my humble opinion...

Paul G.

 

Many Thanks Daniel. Please pass along my gratitude to the team for their work... I hope most everything I've said can be taken in the spirit in which it is intended, - i.e. that of constructive criticism, - notwithstanding my obvious frustration right at the top of the thread...

I stand ready to help with any feedback that may be helpful... I'm a dyed-in-the-wool CBUS user, so my interest is only in getting to the best, most stable, and user-friendly software possible.

Cheers

Paul G.