Project Reference Error

[GUIDO22]

Recently I added a reference to my DB project to use the ListView control from MSCOMCTL.OCX This for whatever reason resides on my Windows 7 Development PC - in c:\windows\SysWOW64.

Other users of the DB on my network do not have Windows 7, (they have either Vista or XP). Of course, all have the MSCOMCTL active X and this is found in the C:\windows\system32, folder.

Of course when I put the DB live on the network - the users were unable to access as the DB did not see the reference to the path referring to folder SysWOW64.

I have had to rollback to where I was originally and remove the OCX reference from the database. I am unusure how I can make use of the ListView control despite the OCX file being stored elsewhere on my Development machine to where it is stored on the users PCs... I believe they have to see the OCX references in the same location? You cannot register a second instance of an OCX already registered elsewhere, can you?

Any help would be gratefully received, thank you.

 

[mdlueck]

I have not had an issue with using the TreeView from Microsoft Windows Common Controls 6.0 (SP6) deploying to both Windows XP / Windows 7 machines running 32-bit / 64-bit Windows and Office 2007 / 2010 32-bit edition.

OCX controls will not work with 64-bit Microsoft Office. Perhaps that is the snag you are encountering?

Also, I develop on XP / 2007 and am able to deploy beautifully to higher levels of Windows and Office. I go through a cleanup process prior to deploying a new build:

NT Command Script and Documented Steps to Decompile / Compact / Compile an Access DB
http://www.access-programmers.co.uk/forums/showthread.php?t=219948

Success deploying completely decomplied database to both Access 2007 and Access 2010
http://www.access-programmers.co.uk/forums/showthread.php?p=1217193#post1217193

 

[GUIDO22]

I am using Access 2003 SP3 (VBA vers 6.5) - I cannot upgrade Office due to performance issues on my network - (namely the PCs are too old to support the newer memory hungry versions of Office).

So from what you are saying - it should make no difference where the OCX file resides on the client PCs - the same version simply has to exist somewhere on that client PC.

If I find a version of the file that is older than I have on the Development PC - am I able to simply overwrite with the new version?

Thank you

 

[mdlueck]

The MSCOMCTL.OCX file should already be deployed to the workstations as part of the OS load. Further, since that is an OCX file, it must be registered with the OS's registry. Regsrv32.exe is the way to install / uninstall OCX's from the target computer's registry.

Once the OCX file has been registered on the target computer, that takes care of mapping the class names to where the OCX file is on disk. Your VBA applications do not need to be concerned about where exactly the OCX is on disk. The applicaiton merely asks for a particular class which has been registered.

But like I said, I have not needed to mess with that file on WinXP. On Windows 2000 there were many updates to that file. Now MS has all of abandoned it.

 

[GUIDO22]

The problem persists... I can get the form working on my Windows 7 'development' machine, but when I go to client PCs on the network all exhibit an error as shown on the attachment.
If on one of these networked/client PCs I edit the project , clear the MCCom Ctl checkbox and using Browse re-select it... the feature runs fine on all clients from this point! .... Hooray.

I then run on my development PC and the error shows again .... BOOOOHHH

I cant help thinking that perhaps it is the file version that is perhaps the issue here..?
Devt machine (Win 7) version : 6.1.98.34

Varied Networked 'client' PCs : 6.1.95.45 / 6.1.97.82

I could overcome this by using a List Box instead of Listview control - but this is a little old hat and I was hoping to use this newer control which is functionally more 'rich' and nicer to work with.... any ideas how I can overcome this OCX issue would be greatfully received.... thank you!

 

[mdlueck]

I cant help thinking that perhaps it is the file version that is perhaps the issue here..?
Devt machine (Win 7) version : 6.1.98.34

Varied Networked 'client' PCs : 6.1.95.45 / 6.1.97.82

I develop the other way around...

My primary development machine is WinXP / Office 2007.

Then I decompile prior to deployment with these instructions I shared previously.

Finally I distribute the completely decompiled database successfully to both WinXP / Win7 machines running Office 2007 / Office 2010.

I do not attempt to deploy to machines running older code than I develop on. I believe that is your problem.