BorlandTalk.com

Anders Gustavsson · Guest

Hi all,

This problem has been discussed here before, but I haven't seen any
complete solution to it yet. Right now I think I have found one
possible cause of this error:

The TCrpe.LoadEngine metod has a weakness in it's way to find the
CRPE32.DLL.

It first calls a method GetCommonFilesPath, where it tries to read the
place of the corresponding version of Crystal Reports. If you have
Crystal installed on your computer - and a lot of programmers might
have Smile

- you will not see the problem, because the right DLL:s will
always be there.

If you don't (and users might not) have CR installed, the component
will just try to open CRPE32.DLL in whatever directory that happens to
be at hand - that is not trying to set any directory. The thought might
be that the DLL should be in the working directory of the app (or maybe
in the search path?).

This means that if you
A. have the application start in the same directory where you have
the correct DLL
B. or maybe happen to have the correct DLL in the search path, and
not an old one?
C. and don't try to change the working directory eg by using an
OpenFileDialog

everything will work all right!

We installed our version 10 CR DLL:s in the application directory, and
it used to work fine. But some customers reported random occurences of
the title error message. As far as we can see now, it happened to them
after opening a file through our app in a directory not being the app
directory.

As I think the proposed way for Crystal installations today is to have
the DLL:s in the app directory, the code in CRPE32.PAS should change to
sCrpe :=
IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName)) +
'CRPE32.DLL'

Hope this is of some help to someone more - if there are anybody out
there still on Crystal?

/Anders