Log in to post a reply

VSPrinter8 and VSReport8 64bit issues

Posted by: luca.cerutti on 28 May 2019, 9:35 pm EST

  • luca.cerutti

    Posted 28 May 2019, 9:35 pm EST

    We are considering to upgrade to 64bit a legacy MFC application built with Visual C++ 2017 with VSPrinter8 and VSReport8 ActiveX controls, so I was assigned to evaluate the extent of the porting.

    I've downloaded latest (20191.1.1) Component One ActiveX Edition. Unfortunately, included VSPrint8.ocx does not seem to work in 64bit build.
    I did the following checks:
    1) create a simple MFC single dialog application with ActiveX control support in Visual Studio 2017
    2) add VSPrinter8 control to the dialog without any further implementation
    3) build on x64 platform
    4) The application crashes at dialog DoModal() call.
    5) Checking the output log (see attached file, line 37) it is confirmed that expected .ocx is loaded (C:\Windows\System32\VSPrint8.ocx)
    6) Test application built on x32 platform has no issue.

    Also VSRpt8.ocx is present only in SysWOW64 and not in System32

    If needed I can provide the Visual Studio test project.

    Waiting for your feedback.

  • luca.cerutti

    Replied 28 May 2019, 9:38 pm EST

    My bad, wrong attachment.

    VSPrinter8_testlog.zip

  • luca.cerutti

    Replied 3 June 2019, 12:18 am EST

    Sorry to bother, but please let me know.
    If we cannot make the control work, VSPrinter will be simply abandoned.

    If you need more info than the already attached log, please ask.

  • Pragati.Kaushik

    Replied 3 June 2019, 10:01 pm EST

    Hi Luca,

    Sorry for the delay in replying to you. The issue somehow got missed in the loop.

    I tried replicating the problem on a Win 10 64 bit machine at my end, however the error could not be demonstrated. Could you please share the project reproducing the behavior so that I can investigate the problem further?

    >>Also VSRpt8.ocx is present only in SysWOW64 and not in System32
    We do not have 64-bit version of VSView Reporting controls.

    Thanks,
    Pragati

  • luca.cerutti

    Replied 3 June 2019, 11:31 pm EST

    Hello Pragati,

    thanks for your kind reply.
    Attached you'll find the simple VS 2017 project I used to test.
    The Win32 build works on my system. The x64 always crash.
    Also, two .txt log files from standard debug output are in the root folder, hoping they could be of any use.

    Please let me know.
    Best Regards

    I hope it will come useful to understand what may be the cause of the problem.VSPrinterTest.zip

  • Pragati.Kaushik

    Replied 5 June 2019, 10:21 pm EST

    Hi Luca,

    Thank you for sharing the project.
    Please give me some time to replicate and investigate this issue. Will get back to you soon.

    ~Pragati

  • Pragati.Kaushik

    Replied 9 June 2019, 10:26 pm EST

    Hi Luca,

    I am sorry but I could not run this application at my end. I tried in several environments including VS 2017, but in vain. It throws the attached error.

    Can you please let me know what do I need to do in order to run this application at my end and observe the issue?

    ~Pragati

  • luca.cerutti

    Replied 26 June 2019, 7:32 pm EST

    Hello Pragati,

    sorry for the late reply but I have been on leave.
    Just to understand, when you have this error? When you build the application in Visual Studio or when you launch it in 64bit build?

    Because if it is when you launch it, it seems more or less the reason because I asked for your support.
    Just to sum up what happens on my system.
    1) the project builds just fine both in any configuration
    2) the 32bit application works just fine
    3) the 64bit application crashes almost the same way it crashes on your system

    The project has no requirement whatsoever, is the most basic Windows MFC Single-dialog application you can build from Visual Studio project wizard.

    Best regards

    Luca

  • luca.cerutti

    Replied 1 July 2019, 6:26 pm EST

    Hello,

    any luck in reproducing the issue?

  • Pragati.Kaushik

    Replied 3 July 2019, 1:23 am EST

    Hi Luca,

    I am sorry for the delay in replying to you. I was trying to reproduce the issue in different environments at my end. Finally, I could replicate it on a Win 10 machine with VS 2015.

    I have escalated the problem to the developers (internal tracking ID: 387308) and will let you know once there is any information from them.

    Thanks,
    Pragati

  • Pragati.Kaushik

    Replied 7 July 2019, 7:35 pm EST

    Hi,

    I discussed the case with the developer. As per him, ActiveX controls are not referenced directly by applications - or should not be. They are loaded into the application through the registry, so it is imperative that for development machines, both the 32 bit and 64 bit versions of the OCX files are registered using regsvr32.exe. There should be unique paths to the OCXs listed in the registry with the Default value specifying the location of the OCX.

    The path to the 64 bit vsprint8.ocx is specified by the default value of the key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{819F123A-B24A-4eb8-BED1-B5DFC5CB5194}\InprocServer32


    and the path to the 32 bit vsprint8.ocx is specified by the default value of the key:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{819F123A-B24A-4eb8-BED1-B5DFC5CB5194}\InprocServer32



    The 32 bit OCX must be registered on a development machine because Visual Studio is a 32 bit process and cannot load the 64 bit version.

    A 64 bit program will seek the CLSID guid in the 64 bit part of the registry (i.e. not under WOW6432Node) which gives the path to the 64 bit OCX which can be loaded by the 64 bit program. Thus, if only the runtime is need by the end user, only the 64 bit version of the OCX must be registered.

    However, there are other issues for 64 bit. All of the dependencies must be installed. For example, if you are using a DataControl, or some kind of DataBinding that VSPrint8 depends on, you must also install the 64 bit version of those dependencies.

    Thanks,
    Pragati

  • gennesseaux

    Replied 9 July 2019, 6:21 am EST

    Hello Luca,

    Did you manage to get a working x64 version?
    If so, could you share it?


    thanks

  • luca.cerutti

    Replied 15 July 2019, 8:35 pm EST

    Hello,
    sorry for the late reply. Got tangled in another issue.
    I checked the registry key you pointed out and I can confirm that the components seem correctly registered. In the attached zip you will find screenshots of keys and file properties.

    As double check I did the following:
    1) uninstalled ActiveX Edition
    2) cleaned up registry keys with specialized product
    3) re-installed ActiveX Edition
    4) checked registry keys. OK
    5) checked file paths and files. OK
    6) re-opened the test project I sent, deleted from simple MFC dialog the VSPrint.ocx.
    7) opened Visual Studio Toolbox. Used the "choose items" options, selected from COM components "VSPrint8"
    8) added again to the Dialog using drag&drop from toolbox.
    9) rebuilt both x64 and Win32 solution
    10) launched both x64 and Win32 solution
    Debug output confirms that .ocx is loaded from the correct path, Win32 works, x64 crashes.

    Since the test solution is the most basic MFC Dialog application, we can exclude that there are dependencies or data bindings, so either there is something wrong in how Visual Studio places/calls the OCX in the dialog form or there are other issues.

    Hope it can be useful.
    Best Regards.

    Luca Cerutti
    VSPrint8_issue.zip

  • Pragati.Kaushik

    Replied 18 July 2019, 9:33 pm EST

    Luca,

    I am discussing your findings with the developer. Will let you know once reach to a conclusion.

    ~Pragati
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © GrapeCity, Inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.