Solved

MSACAL70.OCX Woes

Posted on 1998-05-28
9
699 Views
Last Modified: 2010-05-18
Problems deploying an application written in VB5.0 which utilizes this rather nice calender control shipped with VB5 (SP3 ?) called msacal70.ocx "Microsoft Access Calendar Control". Shipping program using MicroSoft VB Set-up wizard. Everything registers ok on destination PC except for this control. It replies that "An error occured while registering the file c:\windows\system\msacal70.ocx".
on launch OK until "Runtime error 339 msacal70.ocx not correctly registered. File is missing or invalid" which occurs as soon as the control is called from within the program. The quick fix was to install a minimal VB onto the destination PC. This worked. However installing it on any other PC causes this problem. Note! Access/Office NOT installed on destination PC. Anyone had similar problems. Yes I have checked that the setup wizard is used correctly and that it is definately referring to the control before making installation disks.
0
Comment
Question by:StewartWood
9 Comments
 

Author Comment

by:StewartWood
ID: 1461878
Edited text of question
0
 
LVL 18

Expert Comment

by:deighton
ID: 1461879
I've had similar problems like this

Is MSACAL70.OCX actually installed ?

Look in SETUP.LST for your installation disk.  Is the OCX there?  is any further info given?

Use windows explorer to search the directory containing the OCX.  Use option advanced - containing  text, to search for the string selfregister - if found the OCX is self registering and this should be reflected in your .LST

You could also run REGEDIT /v on the installation PC to see if any registry info has gone accross (This is complicated though and I'm still studying this myself)
0
 
LVL 1

Expert Comment

by:JayMerritt
ID: 1461880
Remember that the OCX is not inclusive.  It is just the vehicle that gets you to the library (DLL).  Make sure you have included all DLL's the control requires.

Most OCX files for developers ship with a .DEP file which lists the dependancies for the OCX.


0
Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

 
LVL 6

Expert Comment

by:clifABB
ID: 1461881
Check for a file called msacal70.dep on the developement machine.  It will give you the dependant files required to install msacal70.

I submit this as a comment.  If it solves your problem, let me know and I'll resubmit it as an answer.
0
 

Author Comment

by:StewartWood
ID: 1461882
Thankyou for the above assistance. Yes it is in the setup lst, no there is no DEP file for MSACAL70.OCX. Will probably invest half a day and write my own calender control. VB's Date variables are pretty handy. Shame thought as it's a handy OCX. I shall leave this question pending for the moment but thankyou for your comments
0
 
LVL 6

Expert Comment

by:clifABB
ID: 1461883
There is another file called Vb5dep.ini located in the setupkit\kitfil32 directory under VB5.  This might tell you what you need to know.
0
 
LVL 6

Accepted Solution

by:
clifABB earned 50 total points
ID: 1461884
I ran a dependency walker on MSACAL70 and found the following:

Here is a list of files that MSACAL70 probably needs:
MFC40.DLL
MSVCIRT.DLL
MSVCRT.DLL
MSVCRT40.DLL
Make sure these files are part of the setup.

In addition, these files may also be needed:
OLE32.DLL
OLEAUT32.DLL
RPCRT4.DLL

0
 
LVL 6

Expert Comment

by:clifABB
ID: 1461885
Oops.  I forgot one that should be in the second list:
ADVAPI32.DLL
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1461886
I had a similar problem recently, and this turned out to be the problem.

It seems that the file MSCVRT40.DLL in my WinNT\System32 directory was some OEM-installed version of which Microsoft was not aware. This file is the "C" Run-Time DLL, and was not working with the SetUp program.

      The Official Microsoft release is:
           File Version: 4.10.6038.

      The BAD OEM version was:
           File Version: 4.20 - OS use only. DO NOT DISTRIBUTE

You can look at the version of the files my right-clicking on the filename then choose Properties, then Version.

If this is not your exact problem, you might get lucky and find some strange file version in one of your other files!

Good Luck!

kfrick
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Introduction In a recent article (http://www.experts-exchange.com/A_7811-A-Better-Concatenate-Function.html) for the Excel community, I showed an improved version of the Excel Concatenate() function.  While writing that article I realized that no o…
Background What I'm presenting in this article is the result of 2 conditions in my work area: We have a SQL Server production environment but no development or test environment; andWe have an MS Access front end using tables in SQL Server but we a…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

839 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question