blank (white) where images should be

BarryStevens

I am having an issue install OI 9.3.2 on a hosted server.
I also tried installing SRPEditor, it installs and runs, but I see no images on menu line and nothing in LH panel.

Can this possible point to where the server setup issue is. (It has to be them, not me, as this works on my PC and I copied from that.
Dialogs and Read only is ok)

DonBakke

@BarryStevens - That's a classic sign that the OCX file (SRPEditor.ocx) didn't get registered.

BarryStevens

I did right+click run as admin.
The hosting site people did change it to not ask for password. (It is local , so contact is easy)
I dont think that part is working.

Where in the registry do I look.?

Clientsetup - cant access the net!!!
(I am pretty sure they are just venturing in this area - run very slow, I did think my client , who is transfering from a very fast hosting site to this is going to be happy. I am going to insist they 'test drive' first before committing.

DonBakke

I'm not sure if this is the same for all installations, but mine is found in:

Computer\HKEY_CLASSES_ROOT\TypeLib\{31D674AF-D7F7-4D2B-9665-6F568037F36E}\1.0\0\win32

Remember, the ideal location of any OCX is in a local drive.

BarryStevens

Thanks.

BTW:
Changed the DEP setting (After contact says 'Whats that!!)

msg says after change that 'need restart', so will need them to do that of course.

BarryStevens

SRPEditor.ocx is in that registry setting.

DonBakke

There might need to be other settings that are pertinent. When I search my Registry for "SRPEditor.ocx", it appears in many places. This makes sense because the SRPEditor.ocx (like SRPControls.ocx) encompasses multiple controls, and each control has an entry in the Registry. Thus, it might be possible for the control to be unregistered yet remnants still exist in the Registry. The other possibility is that the path to that folder is being blocked and thus the registered control is simply being prevented from loading.

BarryStevens

>>the path to that folder is being blocked

which folder?

DonBakke

I'm referring to the folder that the Registry indicates the OCX file is located in. By "blocked", I meant blocked by things like AV, firewalls, or other systems that try to protect the computer from perceived threats. I don't mean "blocked" as in you do not have security access to the folder.

As an experiment, I would unregister VSPrint7.ocx and VSPDF.ocx, put copies of these files (along with VSVIEW3-.OCX since it is a dependency) into the folder where SRPEditor.ocx is located. Then I would register them the same way you registered SRPEditor.ocx. Then run OI and open the Table Builder and open a dictionary. Use the File>Print Dictionary Listing and pick the Screen output. Does it work? (BTW, you'll need to make sure CFG_OIPI points to VSPRINTER).

Opto_Will

@DonBakke,

Would you think it good practice to leave VSPrint7.ocx and VSPDF.ocx registered locally, rather than potentially over the network where the clientsetup registered it?

KevinFournier

He's trying to see if there's an issue in general with OCXs registered on the server. If VSPrint7.ocx gets "blocked" also, then we know there's middle-man issue.

Opto_Will

@KevinFournier, I get that.

Without hijacking Barry's actual issue, I am asking from the opposite direction though. Once there, even just as a test, is it worthwhile leaving there?

I am only asking because we have had issues with those files previously. Lets say it was because a drive mapping changed or something like that. The previous solution was to register them locally. I personally re-reun the client setup which I can see re-registers those controls to the location of the OI install.

I was just picking up on @DonBakke's previous comment "Remember, the ideal location of any OCX is in a local drive." and am musing if they shouldnt be left registered locally regardless...

BarryStevens

Reports to screen run OK.
Not tried Don's test yet.
Now setting up on terminal server and get form crash issue.
Cant do run-as-admin yest as asking for PW.
Wait for IT people to contact me.

Got it working on server by doing an OI install (seperate location). Dont want to do that on terminal server as that would mean every user they setup on terminal server for would have to do that. Hoping just running Clientsetup from start to finish will fix that.

Very barebones system setup - maybe MSOffice installs stuff that OI needs as never had to run client setup before.

Now looking at the doing the local drive for .ocx registrations seeing I have the oportunity to make those changes.

DonBakke

@Opto_Will,

Would you think it good practice to leave VSPrint7.ocx and VSPDF.ocx registered locally, rather than potentially over the network where the clientsetup registered it?

Yes I do think it is good practice to leave those files registered locally. You and Kevin were both right. I was trying to see if there is a general issue but I am also making the point (if only indirectly) that client files should be registered...now hold onto something...on the client!

I personally re-reun the client setup which I can see re-registers those controls to the location of the OI install.

Exactly, which is a nitpick of mine. This is why I copy all of the client setup related files (and sub-folders like windllfiles and REVCMD) into another folder so I can then easily copy the contents of this folder into any local folder (e.g., C:\Revsoft\OIClient) and run ClientSetup.exe from there.

BarryStevens

@DonBakke

On the rogue server:
ran as admin the srputilies.exe and I see this, which could be relevant to the overall issue.


Also I saw that some data entry forms do run but a few dont, and, the ones that dont have ole controls in them for 'ChadoSpellText.SpellText'. For which the ChadoSpellText.ocx supposedly shows is being rehistered when I register it.
IF I delete these ole controls, then the form then runs.

Srpedit still shows blank fields.

I am not sure what to tell the IT people where the issue is - I have told them before it is an permisiins/access issue and they say it is all opened!!!

Any suggestions.

BarryStevens

IT came back to me and all fixed, the issue was DEP. Mmmmm, that sounds familiar!!!!!