C++ Faults when a TChartListBox is used in a DLL.

[David Berneda]

I've been doing more testing.

I think I got it to work, but the solution is not yet clear to me.

What I did was to include the Delphi units to the exe project (VCLTee.Chart, VCLTee.TeeProcs, VCLTee.TeEngine) and then build it.

What might happen I guess is the units get compiled to *.obj in a different way than when we create them using our "TeeRecompile" tool.

Other settings I tried for both projects are "Link with dynamic rtl = true" , "Runtime packages = false".

Tried with 64bit but I got stuck at an error when compiling the dll, I've changed "_export" with "__export", but:

[bcc64 Error] UnitDLL1.h(16): declaration of anonymous class must be a definition

[rgsolutions]

Glad to see you have made some progress, however, I do not think it will be the solution.

I do not have symbols so I could not follow your suggestion. However, your approach gave me an idea to try and I was able to get the test case to work, but the test case solution is not workable in my applicaiton. Here is what I did.

I took the test case and changed the settings for using "Runtime" linking. I turned it off for both the DLL and EXE so they would use "static" linking. The test case worked. Just to make sure it was all working, I then modified the test case so that it would actually start a form from the DLL by pushing a button on the main EXE form. This all works. (I have uploaded the revised test case for your use).

From this point I tried a couple of things. First was to have the EXE use "runtime" linking and the DLL "static". This situation fails. I then reversed the settings so the DLL was "runtime" and the EXE was "static". This situation works.

From this information, I would have to conclude that my application would have to be all "static" linkage, or based on the test case, I should be able to have just the EXE statically linked. Since I have 17 DLLs in the application, the option to "statically" link all the application is not workable. (This is the main reason for runtime linkage). Also, in the past I tried statically linking all the DLLs and it did not work. There were conflicts in the way the DLLs register classes and the EXE would fault on startup.

So the remaining option to me was to test my application with dynamically linked DLLs and a statically linked EXE. I rebuilt the EXE and ran the application. It faulted on startup. I changed the setting back and rebuilt the EXE. The program starts up successfully, but still faults like the test case when I attempt to use a TChart in the processing. In order for my application to run, everything has to be runtime linkage, so the test case situation is not viable.

I have no further ideas for you. I do not think this issue has anything to do with your TeeCompile tool. I think it has something to do with the way your are handling the new TeeGDIPlus processing. If I go back to your XE4 Beta release, all of this works correctly and there is no problem. (I believe your TeeCompile was the same back then.) When I move to your official XE4 release (May 2013 - which I believe really started to use the new TeeGDIPlus), the problem appeared.

Is it possible to find out what you changed between XE4 Beta and the May release that might be causing this?

One final note. I would not mess with 64bit C++. Packages are not there and I also have had some strange linking errors in my testing. I have not even had a chance to run my application as I cannot convert it to 64bit. I cannot even use the Debugger as it cannot deal with DLLs. (I have to shut down the entire IDE after each single use of the debugger). I do not believe that 64bit C++ is ready for use, and this is true for XE5.

[rgsolutions]

Any progress with this issue?

[rgsolutions]

I was trying a couple of other things. It looks like if there is any type of control in the DLL that forces the TeeGDIPlus to be linked (at runtime) will cause the fault in the DLL. For example: If I have a form in the DLL that contains only a TChart, the processing will work. If I drop a TChartListBox or TChartEditor on the form, the DLL will fault.

From my previous testing, it appears that this fault is occuring when the DLL is linking to the TChart runtime packages, specifically the TeeGDIPlus processing. We know that using TChart static package linking does not fault, only the runtime, and only if TeeGDIPlus is being included.

[rgsolutions]

Any progress?

[rgsolutions]

Is there any further update regarding this?

[David Berneda]

I've submitted a new issue to our bugs database to keep this problem alive:

http://bugs.teechart.net/show_bug.cgi?id=522

Still can't identify the exact cause. I'd like to try to reproduce the problem without using any TChart module, just using the GDI+ units to check if the problem is there.

[rgsolutions]

Thanks for the info. Since this is now logged as a problem, I have reverted back to the XE4 Beta release.

Knowing what we now know, I decided to conduct a test. You should note that I can make the XE4 Beta release fail in the exact same manner, but it is a problem that I can avoid. If I open a TChartEditor from the DLL and then select 3D / Render / GDI+, I will get the same failure as in the test case. I suspect that latter releases (June and November) now use GDI+ rendering as a default for the internal drawing (i.e. TChartGalleryPanel, etc.) thus causing the hard fault and the inability to dynamically use the package in a DLL.

[David Berneda]

I've just tested the project with "XE5 Update 2" and it works fine, the AV exception does not raise.
Attached the project opened and saved with "XE5 Update 2". I've added Dependency from Exe to DLL so
the IDE will recompile both projects when changing something in the DLL project.
I've added another Chart using GDI+ canvas in the DLL form, just for testing.

bcb_dll_av_bug_522.zip

(54.12 KiB) Downloaded 2064 times

[rgsolutions]

I just noticed your last post a couple of weeks ago. Your posts do not give me an automatic email notice and I really had no reason to expect anything until the last update came out. When it came out I rechecked my posts.

I waited to today to do anything as this is the first time I was able to get to the new update. I figured this would be a good starting point. Unfortunately, I was not able to use the update as it comes up with a missing entry point when I start the IDE after installation. So I reverted back to the only version I have been able to use (XE4 Beta from April 2013).

I decided to try your revised test case. I downloaded the test case and created a new directory. I loaded the test case into the new location. I started the IDE and opened the project. When it compiled, it asked for the 919 files and I substituted the 918 versions. When it went to link, it was looking for the 919 lib. This is not unusual in C++ and I took my usual approach to fix it. I closed the IDE and opened the project files (both of them) in Notepad and replaced the 919 references with 918, and then saved the files. (This is a standard procedure for us C++ people as not all the references in the project files are updated by Embarcadero software, and I have to do this for each project file when I move to a new Embarcadero release. This is one of the reasons I do not like to go to new releases).

I started the IDE and selected the revised test project. When it is loading the project, I now get an error (Form Error). I ignore all of the messages and the project opens. I then did a build of the DLL and EXE. When I run the EXE, I get the TChart not found error (attached). Bottom line is your test case does not run in my current environment. I do not know if it fails on the latest, and I would like to know that piece of information before proceeding.

As for XE5. I have no reason to move to it as there is nothing in the C++ stuff that pertains to me. I have looked at the Embarcadero Roadmap, and I see nothing in there for XE6 that pertains to my development environment. The reality is, until they do 64bit packages (in C++), there is really no reason for me to move forward in the Embarcadero releases as I am stuck on 32bit.

Let me finish with this. I am really curious as to why your test case works for you on XE5 and not work for me on XE4 (with XE4 Beta). I am hoping it has something to do with your latest update, but I have no way to check this out. I think the best way to attack this is to get your latest update running on XE4 for me and then I can test it out. Then, if the update does not work, then I would have to seriously think about testing XE5 or maybe XE6. The other issue I face is that I paid for a year's worth of maintenance from Steema, and I have yet to be able to use any of the updates during that period of time. My maintenance plan will expire in June and I am not sure I will be in any different position with this by then.

Needless to say, I have become very frustrated with situation. I am in a situation that the way forward is uncertain, and quite possibly impossible.

[Narcís]

Hello,

I just noticed your last post a couple of weeks ago. Your posts do not give me an automatic email notice and I really had no reason to expect anything until the last update came out. When it came out I rechecked my posts.

I'm sorry to hear about your experience. We will investigate what the problem is.

Regarding your technical problem, I could run your last test case in XE4 using our current sources. I'm going to send an email with the URL to download them so that you can check if the problem is solved at your end.

I think the best way to attack this is to get your latest update running on XE4 for me and then I can test it out.

Replacing 919 references for 918 I got the "Class TChart not found" error too in XE4. We will investigate this as well.

[rgsolutions]

I was able to get the latest TChart update installed. (Apparently there is some permission issues with installing an update to a system that had TChart previously installed.) I reran my test case and it still fails. Your test case fails as well with the TChart not found message.

Since you have been able to run both my test case and your test case on XE5, I wanted to try your XE5 runtime files to see if it failed on XE4. However, since I do not have XE5 installed, I was not able to install your XE5 update. (Yes, I know that it probably would not work, but it was worth a try. If it did work successfully, then we could rule out TChart as the problem.) I never did get your email with the latest source link, but it does not matter. I do not think it would work as your latest update does not.

I am fast coming to the conclusion that the culprit here is Embarcadero. While I am able to use your XE4 Beta version, it is very fragile. In that release, you did not make heavy use of GDI+ so I can get by. However, if I do anything to set GDP+ in the charts, the product will fault in the same manner as the test case. Also, regarding the TChart not found problem, do even bother to investigate as I think this too is an Embarcadero issue.

I have one more request of you if you could. Could you please reconfirm that the two test cases work on XE5? For my test case, please confirm that the TChart on the form is being rendered as a GDI+. If you let me know that these two test cases work, then I will have to conclude that XE4 C++ should not be used with your software as it is very fragile and subject to faults. This conclusion will have nothing to do with your software, just Embarcadero.

Once I get your answer (either you will do the test or not), then I can move forward. I guess the next step would be to try XE5 on a trial basis. I am hesitant to do this as I would have to set up a parallel evironment and move one of my project groups forward (about 30 projects of DLLs and EXEs). As I said before, us C++ people have to manually move our projects forward to a new release and for one of my project groups, that can take two or three days. The other issue with XE5 is that it is near the end of its life as I am guessing that XE6 will start to come out in July. It really would not be a good investment at this time as I do not need anything in it and it would be better to wait for XE6. If I wait for XE6, then I will not be able to test things out without a new license from Steema because my license (which I have not been able to use) will expire in June.

What a mess. It isn't your fault, but it is what it is. If you can confirm the test cases, then I can at least point to Embarcadero. Up to this point, it looks like it has been in your software and not theirs (since XE4 Beta worked). Anyways, I have appreciated the help and hope you can help me out on the test cases.

Thanks

[Narcís]

Hello,

I never did get your email with the latest source link, but it does not matter.

It is worth a try as David Berneda included some changes on this field. I used your forums profile email address. Could you please let me know the email address where I should send it? You can drop me an email at narcis at steema dot com.

Could you please reconfirm that the two test cases work on XE5?

Yes, they do.They don't show the mentioned error message.

For my test case, please confirm that the TChart on the form is being rendered as a GDI+.

No, on my machine it is being rendered in GDI, I'm afraid. This would indicate that GDI+ DLLs are not being loaded.

I guess the next step would be to try XE5 on a trial basis. I am hesitant to do this as I would have to set up a parallel evironment and move one of my project groups forward (about 30 projects of DLLs and EXEs). As I said before, us C++ people have to manually move our projects forward to a new release and for one of my project groups, that can take two or three days

You could make a quicker test that is installing XE5 trial and run the 2 test cases. That might give you some indications of the chances of success of your bigger projects.

If I wait for XE6, then I will not be able to test things out without a new license from Steema because my license (which I have not been able to use) will expire in June.

That being the case, we could help on that as well.

[Narcís]

Hello,

Some more information about this:

No, on my machine it is being rendered in GDI, I'm afraid. This would indicate that GDI+ DLLs are not being loaded.

Actually that's the fix. To avoid gettin an Access Violation error, GDI is being used instead of GDI+. Otherwise it crashes. In Delphi one can do what David Berneda explained in this article: TEECHART AND GDI+ INSIDE A DLL. However, this doesn't work in C++.

Also, lots of C++ Builder bugs are being fixed for XE6, it could also make a difference.

[rgsolutions]

After reading David's blog article I finally feel relieved. During the past several months I thought I was going down a very lonely path with no solution on the horizon. Now it looks like there are a couple of options starting to open. Since we have already tried David's suggestion we know it does not work in C++ as the DLLs are loaded before we get access to them. The first real option is to wait for the update that David refers to in his blog. I am hopeful this will solve the issue as this will be the one that is most effective and under the control of Steema. It would not depend upon a fix from Embarcadero.

If that does not fix the problem, then the next choice is to wait for XE6. After a heavy discussion on Friday, I too discovered there are to be a lot of fixes in XE6. I really hope the first option works as this will be more immediate.

As a note, I looked at the email address for me in my profile, and it is correct. I am not sure why I did not get your email.

Again, I would like to thank you for all the patience and tolerance you have shown me during this ordeal. When you got involved, I finally felt that we started to make progress toward some type of solution. We're not there yet, but we are moving forward. C++ developers are the step children in the Embarcadero world and often times we do not get the attention or understanding that we would like.

Thanks again, and please keep me posted should you have any relevant information.