Well, I'm here again with a new problem. When I try to run LISTBASIC from the System Monitor, no matter what parameters I set, I get an error saying "Fatal Error with the OIPI INIT, message: -5". Any clues? Thanks.

Stefano

Did you first run Set_Printer("START32") from a stored procedure or at least type "RUN SET_PRINTER 'START32'" from the System Monitor's command line?

This, IMO, should be something that Revelation resolves by the next release. There is no reason why the OIPI32 can't be initialized automatically when OI loads…especially if OI tools themselves are going to use this product.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks a lot. Just another question, is there any reason why OIPI only works if UTF8 character mode (in the Application Properties) is disabled?

Stefano

I believe this is still an open issue. Here is Pat McNerthney's response to this issue before 4.1.2 was released:

*

M@,

You are correct on all accounts!

First, there is a bug in the ANSI to UTF8 conversion routines that is doing the truncating. This has been fixed just now.

Second, I forgot that OE is communicating to OIPI using the Basic+ routine SendMessage. Currently, SendMessage is mapped directly to the USER32.DLL:SendMessageA API. Thus, the UTF8 characters never get converted before they are handed off to OIPI because SendMessageA is being called directly.

If you want to pursue this route, if you redeclare the SendMessage routine to instead map to UTF8.DLL:SendMessageUTF8, then OIPI will be happy. Note that the SendMessageUTF8 entry point has the logic built into to automatically convert the UTF8 data if needed and to call either SendMessageA or SendMessageW, all depending on the character mode you are running in.

Pat

*

Matt did try the above suggestion but it still didn't work. However, in a response to that Pat recognized another issue which he thought would be fixed in 4.1.2. Since then no one that I've seen has suggested whether the above fix will work now. You may want to try it and see.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Stefano,

The LISTBASIC command contains logic to start OIPI32 if it is not already running, so I'm not certain the using SET_PRINTER("START32") will solve your problem. Have you tried running a separate OIPI report? If so, do you get the same results? If you get the same results the following link may help you:

http://www.revelation.com/__8525656100571cbb.nsf/0/db6fe3bc915c663d88256b6c007c39e5?OpenDocument

I'll look into the UTF8 issue.

Sean

Stefano,

Because… …see this thread:

- Oystein -

Oystein,

I thought that issue only meant that the OIPI would not display Unicode correctly…not that it won't launch.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

You're probably right. When I saw "OIPI" and "UTF8" I just immediately thought of that old thread.

- Oystein -

Sean,

Thanks for your help. Please try this: 1) launch OI logging into the SYSPROG account, 2) run LISTBASIC from the system monitor (it should display ok), 3) close OI, 4) restart from the beginning (steps 1-3) and you'll see that OIPI fails to initialize. Why? Just open the task manager and… ooops, OIPI is still there!

Stefano

Stefano,

Then this is because of a reverse problem of what I originally said. Revelation is not issuing a STOP32 command. Of course they shouldn't because they don't know if other OI components still need the OIPI to be running. However, this is still why OpenInsight itself should execute a START32 upon launch and a STOP32 upon closing.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

I'm hopeful that the OIPI stuff will be 'internalised' and re-written into RBasic. When I talked to Tony at Vegas he expressed the view that - with the new OCX etc support - this would be particularly desirable, not be a major issue and would provide many performance benefits including getting rid of this problem of Start / stop.

Of course the oustanding issue is the OCX control and all this extended character set stuff. Hopefully the way forward may be clearer by next year.

It would be best if it was part of the package ..

Of course there could be some licensing issue ..

dsig@sigafoos.org onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 971-570-2005

OS: Win2k sp2 (5.00.2195)

OI: 4.1.2

DSig,

That's the point, there is no more licensing issue. OIPI32 comes with OI32 so there can't be any conflicts with licensing as there used to be. For that matter, the OIPI.LIC file should go away as well.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

OIPI.LIC will not be going away for a while. We've had some developers take the OIPI/OIPI32.exe and try to copy it back to other, older systems where they hadn't had Works licenses, etc.

I'd like to make it go away, but it'll be some time.

Mike

Mike,

Will you be able to eliminate the need for START32/STOP32 in some future version or maybe even in the 4.1.2 ?

Thanks,

Ray

Just thinking out loud here, but I would think that it would be relatively simple to code the OIPI.EXE so that it responded to a unique key that OI 4.1x sent to it. That way if someone tried to copy the OIPI.EXE to an older non-Works OI it wouldn't work at all.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Probably, but not in 4.1.2 - it is a done deal. We'll look at it for 4.1.3, due out in the Spring.

Mike

Thanks again for your responsiveness.

Ray

Mike,

If you address the elimination of the stop/start in the spring update, maybe this provides an opportunity to pick up several OIPI issues such as the licence etc (assuming the code is tight-bound to the OI release.

View this thread on the Works forum...