1. IT Crew
  2. PowerBuilder
  3. Thursday, 4 February 2021 10:19 AM UTC

Hi all,

as discussed in my last question Use of CrystalReports .NET DLL in PB 2019, we managed to get this CrystalReports DLL (32 bit) work to be used in the PB IDE and even in the compiled 32 bit version of our application.

We are using PB 2019 R2 Build 2353 and now want to deploy our application as 64 bit.

As the PB IDE is 32 bit, we can only use the 32 bit version of the DLL here when placing the CrystalReports preview in a window, but for deployment we would need the 64 bit version of the DLL.
Is there any useful way to do this?

Any help is appreciated, so thanks in advance.

BR Olaf

Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 4 February 2021 12:00 PM UTC
  2. PowerBuilder
  3. # 1

According to Appeon it should be as easy as just having the 64 bit installed: 


But the other link with Yakov Verde solution was also about using 2019 R2 I think.

Maybe something's improved with R3, but when searching on the fixes I don't see any mention of ActiveX on 64 bit improvement of fixes.

There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 4 February 2021 11:28 AM UTC
  2. PowerBuilder
  3. # 2

Hi Olaf, nice to hear you've got it working (at least for 32 bit).

For the 64 bit version, please see this link: https://community.appeon.com/index.php/qna/q-a/64bit-ocx-does-not-work-with-a-64bit-executables
t seems that Yakov Verde got a control "somehow" working by using a dynamic approach (read in order from Oldest to newest and read everything). I'm not so sure if that's an easy path to follow though.
You would also need a separate 64 bit installer as things will be registered in different folders in the registry.

I am able to instantiate the 64 bit calendar control at runtime in a 64 bit application using the InsertClass( string s) method.  The trick is that you have to place an empty control (Insert Control OLE- Create New -- choose the empty line).  Although named the same in PowerScript.  They are internally different

type ole_2 from olecontrol within w_calocx  //---This is the generic

end type

type ole_1 from olecustomcontrol within w_calocx   ///-- this exposes events

end type

I inspected our application code.  The positive news is that we only do function calls and property settings.  There are no custom control event scripts. It may be possible to work-around IDE limitations using the dynamic approach

  1. Yakov Werde
  3. Tuesday, 2 May 2017 19:10 PM UTC

Now even if this might work, this does seem a pretty difficult approach to me. Not only for having to do things dynamically but also for testing.

Here's just an idea:
Why not try to create a Winform application in .Net that uses the crystal report viewer control that you already have.
Then call that winform app from a function in a .Net DLL (that DLL has to be non visual)?
Use the DLL importer tool to import import the DLL's function to load the .Net Winform app.
The winform app would have to receive and return values from the function in the DLL

  • I have not tried this myself but I think it should work.
  • The disadvantage that I see is that you can no longer show the control on a Powerbuilder window.
  • The advantage that I see, is that you can get rid of the installer for the ActiveX !!!

Kind regards,


There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.