Runtime Exception with 2017.22 and C++

[RG Solutions]

I just installed C++ Tokyo Update 1. This is the first time I have used Tokyo as the base release had too many issues for me to migrate from Berlin. I have installed the latest 2017.22, updated my project files, and compiled all my DLLs and EXEs. When I run the EXE, I get the message "raised exception class EFilerError with message 'A class named TTeeFilter already exists'."

You should note that this EXE has many DLLs and two them have the TChart library linked (runtime) in them. I did not have any problems with the Berlin or Seattle releases. I have uninstalled and reinstalled the software and still have the same problem.

[Sandra]

Hello RG Solutions,

Could you attached for us the project you're try to migrate to Tokyo because we can reproduce the problem here?
Also, would be very grateful if you tell us which TeeChart version you used in Rad Studio Berlin and Seattle IDE's. Could you tell us, the version?

Many thanks for your collaboration

[RG Solutions]

I think you might have missed what I said in the original post, but I will clarify. It is not a single project I am migrating but a group of them. I have a project group that contains many projects. The main processing consists of 17 DLL projects along with the main EXE project. The EXE uses all 17 DLLs for its processing and these are loaded at program start. Of the 17 DLLs, 2 of them use and include the TeeChart processing. These DLLs link TeeChart processing as run time linkage. They cannot be linked statically as the DLLs will get similar initialization problems and cannot be run in that manner. If I had to guess, I suspect that the processing is trying to initialize the TeeChart processing a second time.

You also asked what TeeChart version I was using in Berlin. It is the same version of TeeChart (2012.22). However, as you know, the Tokyo processing is using the Delphi25 code and Berlin is using the Delphi24 code. Part of my conversion process is that I have to manually change the TeeChart versions in the project, so I know that Tokyo is using the 925 files and not the 924 like in Berlin.

Finally, you asked for me to send you the project. As I said, it is not just a single project. The entire source project group (all projects) consists of 32 projects containing almost 5,000 files and is 245 MB in size.

In order to approximate what I am doing, you will need to create a test with three projects in the project group. Two of the projects will be DLLs that link TeeChart runtime, and the third project is an EXE that calls each of the DLLs.

[RG Solutions]

I thought about it and figured the quickest way to get this fixed is to provide you with a test case. I have created one for you. It has two DLLs and an EXE. The DLLs are very simple and use TeeChart. TeeChart is dynamically linked. When I run the exe, the exception occurs. If there is only one DLL, then there is no exception

[Sandra]

Hello RG Solutions,

Many thanks for your project. I can reproduce the problem you're experiencing using latest TeeChart Pro VCL/FMX v2017.22 in Rad Studio 10.1 Berlin update 2 and Rad Studio 10.2 Tokyo. Also, I have detected the problem is caused because you added two references to ChartGrid through "Worker.h" and "Worker2.h". I'm investigating because it is produced. We give you an answer as soon as possible.

Thanks in advance for your collaboration,

[Yeray]

Hello,

I believe this is similar to this old topic.
Try unchecking "link with runtime packages" in all the dlls.

[RG Solutions]

I looked at your post and considered the information.

In the test case that I sent, it has both the DEBUG and RELEASE builds. The DEBUG build uses "static" linking for the DLLs, and the RELEASE build uses "dynamic" linking for both DLLs. The problem still occurs whether you use "static" or "dynamic" linking.

Please note that I have always had multiple DLLs using TeeChart, and I have always used dynamic linking. Up till now, it has almost always worked. I think I remember a problem once, but it was a very long time ago.

[Yeray]

Hello,

In the test case that I sent, it has both the DEBUG and RELEASE builds. The DEBUG build uses "static" linking for the DLLs, and the RELEASE build uses "dynamic" linking for both DLLs. The problem still occurs whether you use "static" or "dynamic" linking.

I meant the "link with runtime packages" option here:

bds_2017-08-23_11-45-02.png (29.31 KiB) Viewed 22080 times

Please note that I have always had multiple DLLs using TeeChart, and I have always used dynamic linking. Up till now, it has almost always worked. I think I remember a problem once, but it was a very long time ago.

Do you mean the same test project works fine with an older TeeChart version without modifying the option detailed above? If so, do you know which TeeChart version?

[RG Solutions]

I figured out what my problem was. I will explain what happened so that someone else that might have this same issue will know how to fix it. However, I must make one comment.

Regarding your suggestion about make "Link with runtime packages" false. This is great if you have a single DLL or no DLLs at all. However, if you are using multiple DLLs it is almost always necessary to "Link with runtime packages" for two reasons. The first is the size of the files. When you have 34 different object files as part of the install, this takes up a huge amount of extra disk space. The second issue is that with multiple DLLs, if they are not "Linked with runtime packages", then you most surely will have VCL conflicts and the program will not run. The only way I have been able to make my processing run is linking with runtime packages.

Now on to the original issue. The issue with the test case I sent was very subtle. When someone sets "Link with runtime packages" to true, one would assume that all packages used by the processing would be "runtime linked". The truth is that when this option is set to true, it will only link the packages that are included in the accompanying list. This means that in the test case I included, all the VCL packages would be runtime linked, and the TeeChart packages would be statically linked because they were not in the list. Mixing static and run linkages in the same object module does not seem to work well. For this reason, it is necessary to add the TeeChart packages to the list. In the test case, it was necessary to add "Tee925 and TeeUI925". The 925 must be present otherwise the package in the list is not found and is statically linked. If you add these two statements to the two DLLs, the test case will work.

Now on to why I had a problem. When moving from one Embarcadero major release to another (i.e. Berlin to Tokyo), it is necessary to manually edit the project file if you are using third party software. (This is at least true for C++). What I have to do is to identify and edit (with notepad) each project file that has references to the third party software. In the case of TeeChart, when going from Berlin to Tokyo I will have to replace each instance of 924 with 925. Once done, I save the file. When I get them all done, I can then open the project group and compile all the files. One note. When you take an older project and try to compile it with a newer version, the processing will ask for you to locate the new package that is required because it cannot find the old one (i.e. the 924 package). You then navigate to the new file (i.e. the 925 package) and indicate to the processing to use that file. You might think that this action will cause the processing to change all the references to that package to be change, but you would be wrong. Some of the references remain unchanged and will cause issues when you try to link or run the program. The only way to really get the changes made is by manually editing the file with notepad.

Finally, what did I do wrong. I missed one reference and did not notice it. I had one package that was from 924 and was not dynamically linked in.

If you would like, I have uploaded a revised test case. It is a corrected version that will run on Berlin. If you would like to run it successfully on Tokyo, then you will have to edit the projects to use the correct versions.

[Yeray]

Thank you for such a complete explanation!