Setting Up OI Workstations v7.0 (OpenInsight 32-Bit)
At 03 MAR 2004 04:58:28PM Warren wrote:
How does one setup OI v7.0 workstations?
Network: Novell 3.x, NLM v1.5
Workstations: WinXP Pro, Novell client v4.83sp2
Thanks
At 04 MAR 2004 01:01AM Donald Bakke wrote:
Warren,
Fundamentally OI is relatively self-contained and doesn't require a client setup anymore. However, the two OIPI OCX files need to be registered on each workstation in order to work. From a command line you would simply do the following:
RegSvr32 application path\VSPRINT7.ocx
RegSvr32 application path\VSPDF.ocx
You can create a simple installation to do this for you, create a batch file for end users, or simply have OI do it automatically when the application launches.
At 04 MAR 2004 01:36PM Warren Auyong wrote:
How do you have OI to self-register these?
At 04 MAR 2004 01:58PM Jonathan Bird wrote:
I've found on some occasions that OI does NOT register the OIPI components. Why would that be?
At 04 MAR 2004 04:47PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
When your OI app starts up make a call to the regsvr32 program just like in Don's example but add a /s switch to make the install silent.
(run "regsvr32 /?" at the command prompt for more info)
World leaders in all things RevSoft
At 04 MAR 2004 04:48PM Tony Marler wrote:
Just have OI shell out and run the REGSVR32 commands in the login/startup process.
Tony
At 07 MAR 2004 01:51PM Warren Auyong wrote:
Ah, ok. Seems like overkill to do it every time OI starts and too much trouble to add runonce logic to it. A bat file works.
At 08 MAR 2004 11:19AM Warren Auyong wrote:
Ok, I did this. No joy. Reports still won't print or preview.
I tried using UNC for the path as well as drive:\path. I tried matching case also. XP says the ocx regsiters successfully but reports won't output. Restarted XP also.
User has full admin rights to XP.
At 08 MAR 2004 02:38PM Warren Auyong wrote:
Okay, if I put the OCX files on the local drive and register them it works. It will not work if they are registered from the network.
This is a RPITA if we have to copy the OCX files to every workstation every time they are updated.
At 08 MAR 2004 10:01PM Donald Bakke wrote:
Warren,
Strange. That shouldn't be the case. I wonder if this is a Novell specific problem (at least I assume you are working in a Novell environment).
If you are willing to experiment, try the following:
1. Register the controls back to the network drive.
2. Create a new window with an OLE control.
3. In the Text property editfield enter: VSPrinter7.VSPrinter.1
4. Test run the form.
Do you see anything that looks like the OIPI Preview window? If so, then my guess is that the OLE control is working fine and something else is preventing the logic from executing correctly. If not, then something is definitely not working at the OLE registration level.
At 09 MAR 2004 11:11AM Warren Auyong wrote:
Okay, I tried what you suggested and the OLE control work.
I then tried running one of the reports and it worked.
Just to be sure I then deleted the local copy of the OCX files and it still works.
WFT???
I'll try this on another XP machine and see what happens.
At 09 MAR 2004 12:09PM Warren Auyong wrote:
Ok, tried it on another XP workstation, although that one has the Novell v4.9 client on it (slowwwwwwwwwwwwww).
The OLE control worked in the form. I didn't actually run a report must most likely it works.
So as it tried to say earlier: WTF????
At 09 MAR 2004 12:50PM Warren Auyong wrote:
Well, never assume.
OLE control works in form. Reports do not generate on the other stations I tried this on.
I'll try the same steps I did on my system and see what happens. i.e. register local, run, register on network.
At 09 MAR 2004 01:40PM Warren Auyong wrote:
It turns out the default printer was not available, but I only determined this after trying the OCX on the local drive so I still don't know if that factors into play.
Shouldn't the preview mode still work or at least give a warning message that the default Windows printer is unavailable?
At 09 MAR 2004 02:07PM The Sprezzatura Group wrote:
It would be nice. However Windows uses the Printer Device Context to render the screen so it does sort of need it to go ahead.
The Sprezzatura Group
World Leaders in all things RevSoft
At 09 MAR 2004 02:15PM Bob Orsini wrote:
If there is no default printer then you should receive a -13 on the init return. Are you sure you have error checking on the init.
At 09 MAR 2004 04:59PM Warren Auyong wrote:
Bob:
What clued me in was when I went into report builder and tried printer setup from the RB+ menu. That would give me the error -13.
However if I just tried to preview the report - nothing. Same with running a stored procedure doing a RUN_REPORT("","some list statement to preview").
At 10 MAR 2004 08:24AM Bob Orsini wrote:
The problem here is that RB+ did not catch the error. Release 7.1 will display the error when the initialization fails.