A couple of client PCs have been having intermittent OIPI INIT -4 problems (aka "The Sandra Bug"). One is using OI 3.7.5 with OIPI 4.01 on Win 98SE and the other OI 4.1.3 on Win 2000. The latter is also having Windows registration problems. At both sites all other PCs are fine and in the latter case all was well until recently and now it falls over all the time.

My laptop has now taken up the habit - having been OK until a hard disk replacement.

Does this suggest a Windows registration problem?

I see from OIPI manual install instructions that 16-bit OIPI needed registration of VSVIEW-.OCX, SSUTIL.OCX and OC25.DLL. In this forum it seems that 32-bit OIPI needs registration of VSPRINT7.OCX and VSPDF.OCX. Does this mean that the above 16-bit components don't need to be registered for OIPI 32-bit?

What about OI 4.1.3 which has OIPI integrated within?

Why does registration sometimes seem to matter and sometimes not?

To add to the fun, the 4.1.3 installation runs via load-balanced Citrix servers, which presumably operate as the real workstations (where I presume registration issues would arise). However, one remote user never has any problems whilst another always now has problems. Strange!

Help and advice very gratefully received.

Oystein

Interesting you've also got the "Sandra Bug" from letting START32 get too close to INIT. Proves it's infectious.

Since posting, I've really hammered on the laptop on which I could reproduce the bug pretty reliably. After quite a few attempts I had one which didn't go first time and then with only one INIT retry. Then I hid the retry and hammered it a bit more and couldn't get it to fall over (error abort after 5 failed retries hasn't yet happened).

Mike

This is good news as getting users to register, alter oinsight.ini, etc. on every workstation, Citrix server, etc. is a real pain. On a new workstation one just wants to be able to set up an icon and go - and users will often do this without knowing.

In fact I haven't bothered to register any OCXs on my or client workstations and problems from non-registration do occur but only very rarely.

Not all our users have chosen to upgrade from 16-bit and that we won't play Leapfrog for a little while until this forum, etc. shows it to be proven bullet-proof. Hence, if it is feasible, could you tell us how you detect during OI logon if OCXs, etc. are registered so that I can add this capability to my logon procedure? This would avoid the few such problems mentioned above.

Thanks.

Richard,

Interesting you've also got the "Sandra Bug" from letting START32 get too close to INIT. Proves it's infectious.

Not me. A client. And it's not certain. So far it's a theory. He hasn't reported back yet if the Delay call made a difference.

Would a lot of comments between the two statements work as well?

Hahahahaha! Just trying to be funny.

- Oystein -

Richard-

This is a moot point in Leapfrog (OI 7.0) as:

1. There is no more start32, as OIPI is now written in Basic+

2. We register the OCXs at runtime if they are not already registered.

Mike

The "Sandra Bug" seems to be cured - and seems to have uncovered a quirk in OIPI.

As noted previously we don't start OIPI at logon but only if and when needed. When this happens START32 is almost immediately followed by the INIT. On all PCs so far the first time after (re)boot this isn't too fast due to disk access. The second time due to read from RAM on a fast PC it seems to happen too quickly and OIPI isn't fully awoken when the INIT fires.

I've now included Delay(0.5) after START32 and then, if INIT fails it retries up to five more times with a delay(0.5) between each.

Whereas on my laptop I could generate OIPI INIT -4 error virtually at will (except first time after reboot), now I can very occasionally achieve one retry.

It's also interesting that the delay(0.5) doesn't visibly slow the OIPI Start/Init process. As an ignoramus in such things I read this that there's a bit going on in parallel and we're now ensuring that the right one wins the race.

For those using the default OIPI 32 start at logon these issues don't of course arise.

Oystein

Firstly, the half second delay call seemed to do the trick but I also put in a retry loop of up to five retries with half second delay between them. As mentioned, once it did have a second go and then I hid the retrying.

Otherwise one could use a longer delay - but as it seems to be OK most times at half second, it seemed better to retry rather than further delay every attempt.

Secondly, that's a great new idea to solve bugs - adding comments to the coding! A bit like singing to cabbages to make them grow bigger and tastier.

Do you think the best effect would be obtained by polite, flattering, angry, rude, complimentary, obscene or what types of comments. Maybe a mix ("carrot and stick") - if so, what percentages of which types?

Should some be displayed on screen?

A new area for experimentation and for discussion of new ideas/comments and results in this forum.

Seriously though, I look forward to hearing if the delay cures. I'm away from my desk shortly for a week but will look for this on return.

Regards

Richard

Richard,

I suggested comments as an alternative to the Delay call. I know comments aren't executed, so these comments would have to be of a special kind - something so interesting the system simply had to spend half a second reading them. Lame joke - I know.

About the 'Sandra bug' - I'm sorry to say my client hasn't got it. There seems it was something else that caused the -4 error code.

- Oystein -

Mike,

This is a moot point in Leapfrog (OI 7.0) as: 1. There is no more start32, as OIPI is now written in Basic+

How come the System Monitor still shows a "RUN SET_PRINTER 'START32'" command when OI 7.0 is being launched?

[email protected]

SRP Computer Solutions, Inc.

For some time now, we've had a Delay(0.5) in our app initialisation code (just 'before' calling START32, actually) to stop a runtime system crashing. Can't remember what OI version that was required on though.

M@

View this thread on the forum...