Further to earlier thread, our subsequent experiences may be of interest…

Three machines :-

1) Networked OI 3.7.5 with W98SE wkstn

2) Networked/Citrix OI 4.1.3a with NT/2000 on Citrix servers

3) Single laptop OI 4.0.3 with XP

All suffered the OIPI INIT -4 error (plus occasional OCX not registered) - although all other workstations on installations (1) and (2) were fine. Putting .5 sec delay between START32 and INIT solved on all three.

Then (1) reported persistent OCX not registered error. OIPI hadn't been installed and doing so cured it.

The others are now running fine and seem to have self-registered. They were first used with OI 4.x without installing OIPI (as it's bits are included in OI itself). In case (3) I searched registry for the OCXs using regedit and there were no referneces. After first run, they were there. In case (2) it would have been the same (OIPI not installed on Citrix servers).

In all cases OCXs located in Open Insight program directory. Although I take Tony S's point of version conflicts, I wonder what else uses VSPDF.OCX or VSPRINT7.OCX. Unless and until one meets such a situation and has conflict problem it seems much better to work simply as described herein.

Any comments?

I agree that your method is much easier for the end-user.

Who or what else uses VDPDF.OCX or VSPRINT7.OCX? – The VSPRINT7.OCX is a fairly common component used in VB 6.0 and VC++ 6.0 applications. There is a new version and other options available for VS .NET. I have seen it used in a few shrink-wrapped applications (like Quicken), but most of the time it is used by custom or enterprise applications (which are unlikely to be installed by the typical OI end-user).

I think your method will work at least 99% of the time, in fact, maybe Revelation could help by incorporating these concepts into OI 7.0 for any ActiveX component that is used in OI directly. That may not be the best idea, because all installation programs that I have used (except for .NET) always put "potentially shared" ActiveX components in the System32 folder. There must be a good reason for doing it, but then again – the components required for the OIPI are somewhat special-purpose, so putting them on the server may be an OK deployment strategy.

Tony

Thanks again.

Anything in the software world which works 99% of the time is OK by me!

At least in this case we know what to look for and what to do when it doesn't.

Richard

Excellent summary on how to make OIPI deployments work. I think this post will help people with OIPI deployments because it is simple and easy to implement.

I will also express my (minor) concern as simple as possible: If the end user installs an application with a different version of the VSPRINTER.OCX, then the OIPI may stop working for that workstation. ComponentOne has maintained the same GUIDs for all versions, which means if someone installs an older version it may break the OIPI. This concern may not be an issue for most deployments, and the benefits of the self-registering method used by Richard outweighs the occasional problems that may occur.

View this thread on the forum...