on 2025 Apr 05 5:02 PM
Hi!
The time has finally come to port our app to 64-bits as support for 32-bit Crystal is ending. We also hope that 64 bits will help with the memory issues we have been having with Crystal. So, basically will the code (C++/MFC) be ported to 64-bits that project is underway.
The app calls:
using namespace CrystalDecisions::Shared;
using namespace CrystalDecisions::CrystalReports::Engine;
using namespace CrystalDecisions::Windows::Forms;
using namespace CrystalDecisions::CrystalReports::Engine;
using namespace CrystalDecisions::Windows::Forms;
For printing. I guess we just install the 64-bit runtime right?
For 32-bits, we also have a two UFL DLLs written aeons ago in C. I guess the proper thing is to rewrite them using the C# .Net stuff? Ie: https://userapps.support.sap.com/sap/support/knowledge/en/1603381
Anything else to watch out for?
Request clarification before answering.
Hi Anders,
I see you have finally decided to move to 64 bit....
Nothing else to do except change your project from x86 to x64. Not sure about Managed C++ but in C# when you change it you'll notice all of the CR References path will change to the 64 bit CR folder.
See this KBA on using C# to rewrite your UFL, sample attached, the one you posted is old when you had to manage string length manually:
https://userapps.support.sap.com/sap/support/knowledge/en/1525014
PS - Memory issues are usually due to not Releasing App Objects, CR Reports, DataSets' etc. Or could be third party leaks. SAP Dev constantly look for them and fix if possible, sometime they are 3rd party and they can't fix them.
If you found some post a new question and I'll get R&D to look into them. PS don't write a simple test app that cycles through report, it take CR about 100 iterations to allow Windows to catch up...
Also, you added using namespace CrystalDecisions::Windows::Forms; twice? is this a typo or are you loading to instances of the Viewer?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just one small addition: The later versions of Visual studio does not take the old APIs insistence on byte padding so to compile under VS2022 you need to do this:
#pragma pack(push, 8 )
#include <windows.h>
#pragma pack(pop)
#include "ufls/ufdllunicode.h"
#include "ufmain.h" #etc
That sets the packing to windows default which is 8 and then back to 1
Hi Anders,
Wow those are really old, CR added those Date functions in CR 7 I believe. You could rewrite them using .NET sample UFL pasted the link to.
For one you can use:
CDate (number)
CDate (string)
CDate (dateTime)
CDate (YYYY, MM, DD)
It will however force you to edit each report.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 6 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.