gottasee

Hi there

Crystal reports have 3 versions which we use
Crystal 8.5, 9 and Now 10

In our project we have to have 3 different versions. 1 for 8.5 one for 9 and one for 10.

Is there a way we can make either the crystal viewer into an activeX control so the user can select which version they have installed? The only problem with this is that the activeX control would have to be an MDI child form.

Or

is there a way we can create the crystal report references and controls on the fly so we can select the correct version of crystal and load the necessary OXC's and DLL's

Thank you

MKoslof

I see the real issue with this being the deployment of this application. How do you plan on deploying this application? Isn't the user going to have to tell you when they first install your app what version of Crystal they are using? (You will need to use Wise or InstallShield, some Installer package that allows you to code and create custom dialogs). Because if not, you will be installing dlls and ocxs for all three versions on top of each other. This will become a nightmare. How do you plan on handling this? And I assume your reports are using the RDC and not the .OCX. What .ocx controls are you including. As of Crystal 9, many of the old .ocx controls are no longer compatible.

gottasee

We already use install shield to deploy it.

Custom screens and all that are already there. We are only supporting 8.5 and 9 as of present.

We use
for crystal 8.5:
REPORT DESIGNER COMPONENT\CRAXDRT.DLL
CRVIEWER.DLL

For 9 we use:
Report Designer Component\craxdrt9.dll
ActiveXViewer\crviewer9.dll

Only the correct version gets installed with the product.

Its just a pain to have 2 versions. Would be nice to have 1 program which can select between 9 or 8.5. The best solution would be to create the controls on the fly.

Any help would be great.

MKoslof

You should have a SET design structure for these reports. Since you are using the RDC and the CRAXDRT object library the overall code flow will be the same. So then, what you could do is when the code is first launched run a case statement or function to determine what version of Crystal Reports is currently installed....store this in an integer or string variable. Then based on this information, you can set some CRAXDRT run-time conditions such as using SetLogonInfo or .ConnectionProperties for logging onto your tables, etc. Since your installation only installs the proper Crystal files to the user's workstation (one version of dlls, not both) at run-time there shouldn't be a lot of tweaking.

gottasee

This is already done.

The problem is that with the 8.5 version of the Crystal viewer it won't work with crystal 9 reports. Hence the origional question.

What you are suggesting won't work simply because if you compile it with 8.5 and run it on 9 your get an activeX error. Same the other way around too.


We need a way of loading in the DLLs when the form loads or making the form an activeX Addin which would need to be an MDI child.

Thank you

MKoslof

If you read my original post I asked you this


"I see the real issue with this being the deployment of this application. How do you plan on deploying this application? Isn't the user going to have to tell you when they first install your app what version of Crystal they are using?"

Scroll up, remember this question? Your reply to me was that this procedure was already handled..obviously its not . You need to install version 9 active x controls for reports created in version 9 and vise versa. I can't think of any good way you are going to be able to do this at run-time. From your installation, you need to be able to detect what version of Crystal they are running or prompt the user...I have done something similar to this before. Then, based on this information you load the appropriate DLLS...you have code and script within your installation to handle this ( I tend to use Wise or InstallShield for my installs because I can build custom dialogs and incorporate script calls). Then, once installed, any run-time issues can be handled within your code.

gottasee

OK we have gotten completly crossed wired.

We have a Large App. When we make a change to it If a customer has Crystal 9 installed we have to compile it on a seperate machine which is slow and takes ages to do.

What i was trying to say in my origional question was i want the Crystal display form to be independant of version. I.E we can compile the program on a computer With Crystal 8.5 and it will run on a machine with crystal 9.

At present you can't load the project with crystal 9 components unless you have crystal 9 installed.

There must be something we can do about this as anyone wanting to display crystal reports in their project and let the user maintain the reports too would have a nightmare with all the different versions.

MKoslof

The CRViewer dll is version dependant. The CRAXDRT.dll is also version dependant. The OCX Crystal Viewer control is not compatible with version 9. Crystal Reports isn't your issue as much as integrating it with VB. There is not going to be a simple way to do this. You are probably going to have to write a dll to handle this for you.

And, I am not sure there "must be a way to do this" . Typically, no software company supports multiple versions within the same application. Microsoft doesn't support installing XP,and then trying to install 2000 on top of it.

gottasee

I know all of this but what i thought was going to be a simple answer is not.

What i was hoping to do was to load the Required DLLs on the Fly so if they had crystal 9 installed then it would load crystal 9 if it had 8.5 it would load 8.5. If we can't do this then we will have to keep things the way they are.


Also "no software company supports multiple versions" ActiveX controls should always support this as otherwise a software company has to re-write their software to use it. All Activex controls should be backwards compatable.

MKoslof

Actually, no. This is why companies encourage upgrading. Try running Microsoft Office 97 dlls in Office 2003...but shouldn't these be backwards compatible too ? VERSIONS of software are typically backwards compatible, but NOT the installation or dependencies....this is the entire purpose of upgrading. You can open a report created in version 8 in Version 9 will no problems. Backwards compatibility isn't even close the to issue here.

Basically you are telling me that "Product" Version 1 and "Product" Version 2 should be installed on the same CPU and the dlls and updates should just magically work together. "Product" Version 2 is an UPDATE from Version 1, when installed it removes all old files and UPDATES and dlls and copies new files into its working directory. This is how software updates work.

gottasee

ok we are getting we away from the point here.

What i'm thinking was using something like
Form1.controls.add "Vb.Label", "LblTitle",Form1
With form1!lbltitle
.visable = true
.top = 0
.left = 0
.width = 4000
.height = 500
.font.size = 18
.Caption = "testing"
end with

for the crystal viewer control. If i can create that on the fly then my problem is sorted. The question is how can this be done with the cryatal viewer control.

MKoslof

OK, let me get this straight. You want to compile and deploy a VB application with no CRViewer present on the form. Then at run-time you want to redraw your form, add a CRViewer, register it, and bind it to a report object...what?

Now, if you HIDE the CRViewer in design mode and then, if a condition is met, make the CRViewer visible and autoExpand it via API (and in turn expand the user form it resides on) this would work. Your real problem is, you can't magically bind a new CRViewer to a report object. You would to create the CRViewer at design time either way. Then, as its report source, use a variable...something you can pass at run-time. So, if a condition is met, you un-hide the CRViewer, expand it to full screen size and basically auto resize your controls. Then, the report loads, and the CRViewer is bound to this report via the variable you assigned at design time.

Now, if you want a way to add a fresh, brand new CRViewer at run-time, it won't happen. But, really think about that logic:

In order to even USE the CRViewer you need to load the CRViewer.dll for that version of Crystal. So, at design time, you have to add a reference to this dll in order to even hide or design the control. So, if this version of the CRViewer.dll doesn't match what CRViewer.dll you have loaded on the user's machine, this whole process is pointless anyway.