Access violation with AdvRichEditor toolbars in DLL


I have found a problem that is tied with the AdvRichEditor toolbars somewhat.

I will try to explain myself as clear as posible.

I have a TForm with a TAdvRichEditor, TAdvDockPanel and some TAdvRichEditor toolbars - Edit, Format, ...). If I use that form inside an exe project (loading with ShowModal, for example) is working fine

I added that form inside a DLL because I need that it could be shown from different exe programs. That DLL is loaded dynamically (using SafeLoadLibrary and GetProcAddress) and has been compiled with C++ Builder 11 on Windows 10.

If I run a C++ Builder 11 (Alexandria) little app to load the dll and launch the form, everything works ok but, and this is the nasty problem, if I load the very same dll from a C++ Builder 2009 compiled app and lauch the form, it pops up as it should but inmediately after that, it produces an access violation, I accept and another access violation appears and so on at infinite. It seems to be on an infinite loop 'cos I need to force an application shutdown to close the program.


I started to do some tests and I found that:

  • If I delete the AdvRichEditor toolbars, the problem is gone.
  • If I set Visible = false in toolbars, the problem is gone.
  • If I set Enabled = false but Visible = true, the problem apperas again.

Looking for advise or a way to solve it.


P.D.: Using TMS VCL UI Pack

What happens when you delayed enable the toolbars, i.e. only when form having richeditor and toolbars is effectively shown?


Thanks Bruno for the reply. This problem is driving me nuts. I thinking even in removing the toolbars and develop my own one.

First of all, I removed all toolbars except one (TAdvRichEditorEdit) just for keep things focused and simple in testings. My initial TForm had the Edit, Editing and Format ones.
And second, the TAdvbRichEditorEditToolbar and TAdvbRichEditor are created at design time. I forgot to pointed it out. Maybe it's important.

Some testings and case scenarios:

  • Edit toolbar Visible = true and Enabled = true at design time -> Problem appears
  • Edit toolbar Visible = true and Enabled = false at design time -> Problem appears
  • Edit toolbar Visible = false and Enabled = true at design time -> Problem disappears
  • Edit toolbar Visible = false and Enabled = false at design time -> Problem disappears

So if the toolbar is hidden, the endless Access Violation dialog doesn't happen at all.

I have tested what you suggested and added a button to the dialog. I set toolbar as Visible = false and Enabled = true at design time and added that line in the button OnClick event:

ToolBarEdit->Visible = true; -> This is the AdvRichEditorEditToolbar

The form pops up fine and no toolbar can be seen. Fine. I click the button and inmedianly the Access Violation dialog starts to appear. And it appears so fast that Windows doesn't even have time to paint the toolbar on the TForm after the Visible = true.

I hope it helps to trace the issue.

Thanks a lot for your support.

I'm afraid to ask but does the lack of updates mean that you find the reason behind that Access Violation?

I'm sorry but we could not find a problem in our code. It looks more like an incompatibility between C++ 2009 and C++ 11 Alexandria.
Have you considered creating the DLL with C++ 11 Alexandria?

The DLL has been build using C++ Alexandria. In fact I thought that TAdvRichEdityor was not available for C++ 2009.

The problem pops up when I call the dll (with the TForm with the TAdvRichEditor and toolbars) compiled with C++ Alexandria from a C++ 2009 compiled executable. If I call the dll from a executable built with C++ Alexandria everything works as expected. I can`t upgrade the C++ 2009 application to C++ Alexandria at the moment. That was the reason of my asking.

TAdvRichEditor requires XE or newer IDEs.
I had confused your situation what was in the DLL and what IDE was used for DLL & EXE.

In the dll there is a TForm with a TAdvRichEdtor and its toolbars. That dll is compiled using C++ Alexandria.

I load the dll dynamically using SafeLoadLibrary and use GetProcAddress to launch the function inside de DLL that created the TForm and show it via ShowModal(). The Dll code is pretty simple:

#include <vcl.h>
#include <windows.h>
#include "Test.h"

#pragma hdrstop
#pragma argsused

extern "C" __declspec(dllexport) void __stdcall ShowTest();

extern "C" int _libmain(unsigned long reason)
   return 1;

void __stdcall ShowTest()
   HWND AppHandle;

      AppHandle = GetActiveWindow();
      Application->Handle = AppHandle; 

      std::unique_ptr<TfTest> Test (new TfTest);
      Application->Handle = NULL;

TfTest only have TAdvRichEditor, TAdvRichEditorEditToolbar and a button to close the form. Everything is created at design time. No code inside TForm unless the ModalResult = mrOk under the button click event to close de form.

The DLL is compiled with C++ Alexandria (Link with runtime packages = false and Link with Dynamic RTL = false).

If I load it with a executable compiled with C++ Alexandria everything works as expected but if I load the dll and run the funcion with GetProcAddress from an executable compiled with C++ 2009, the dll raises an Access Violation if the toolbar is visible. But if the TAdvRichEditorEditToolbar is Visible = false the Access Violation does not happen. That the reason that have leaded to me to think that it could be an issue relating the toolbar.

In fact, I did another test as you sugested the first time you replied to my message:

  • I added another button that only set toolbar Visible property to true
  • I set toolbar Visible = false at design time
  • I load the dll (SafeLoadLibrary) and show the TForm (GetProcAddress) from the C++ 2009 compiled application without issues.
  • I click the button that set the toolbar Visible property to true and ... Access Violation instantly pops up.

Hi, Sorry to bother again. Any progress with this issue?

We have not been able to pinpoint something in our code. It points to C2009 vs C11 incompatibilities but we couldn't find a workaround or solution so far.

Thanks for the time Bruno.

I think I will need to deploy my own toolbar and add it the basic functionality I had using your toolbars.