delphi XE : Access violation inside LoadLibrary() call - delphi

I get an access violation when call a DLL in an project. Both project and dll are use Chart unit (TChart). Remove Tchart from project the LoadLibrary can successful return. It also works if Tchart removed from dll. I don't understand why the chart unit can't be used in both project and dll? And how to resolve this problem.

Sarah, this is a bug of the TChart component, located in the TeCanvas unit. the people of Steema are aware of this. you can check the next Thread Delphi XE, TChart in exe and in dll in the embarcadero forums.

I spotted this bug today while using Delphi XE and FastReport 6 VCL, when in exe I have FrxChart and in a library.
After long time consumption debugging process, I realized that only TeEngine included in both application can cause crash LoadLibrary() function.
Because link to forum is not working anymore, can I do something to repair this bug (excluding remove charts in library)?

Related

Using VCL Styles in a DLL causes System Exception in 10.2 Tokyo

An application originally written in XE2 that uses styles within DLL's so that forms that popup from DLL's are the same style as the EXE, when updated to build in 10.2 Tokyo, now causes System Exceptions when opening certain forms from the EXE, or when closing certain forms in the EXE.
I don't need to include the minimal reproducible example in this question, because I have an answer, that someone else may have been able to add to my original question had it not been closed so quickly, and then not re-opened even after making it on-topic.
Turns out it's a behavioural issue in VCL:
Exception if using comboboxes in a form that resides in a DLL and that uses VCLStyles.
Embarcadero won't fix it as it's not a "problem",
R&D writes that the style manager has to be enabled in the application
and there can be only one one TStyleManager with enabled system hooks
(TStyleManager.SystemHooks property), because it process all windows
from application. The current system doesn't support the scenario you
are suggesting, and there is currently no plan to rework it
but there is a workaround which is to add the following line of code immediately before calling SetStyle or TrySetStyle in the DLL code:
TStyleManager.SystemHooks := [];
Hopefully this will be of assistance to Delphi developers who run into this annoying problem after upgrading to the newer versions.
In my case, I add a conditional define to the project for the libraries, then add this code to the places where it setting styles, as the same unit is included in both EXE and DLL:
{$IFDEF DLL}
TStyleManager.SystemHooks := [];
{$ENDIF}

Delphi - How to correctly register a graphic class since XE8?

I'm writing a Delphi package, which provides a new custom TGraphic object, allowing to read a new image format in VCL components like TImage.
I originally developed this package with RAD Studio XE7, and it worked well. However I migrated recently to a newer RAD Studio compiler version, and although my package continues to work properly on that new version, I noticed a strange bug that never appeared before.
I have a form with several components, some of them are TImage components. Immediately after opening the IDE, the first time I open my project in design time, all the TImage components containing my custom TGraphic component loose their content. If I close then reopen the project, the images reappear, and the bug no longer happen until I close and reopen my IDE.
I dug in my code to understand what may cause the issue. To register my custom TGraphic component, I use the class initialization section, in which I wrote the following code:
initialization
begin
Vcl.Graphics.TPicture.RegisterFileFormat('svg', 'Scalable Vector Graphics', TWSVGGraphic);
end;
However I found that, since the XE8 compiler version, the TImage constructor is called before my initialization section, causing thus apparently the above mentioned issue. All the compiler versions since XE8 are affected, but this bug never happened on XE7 or earlier. So something changed since XE8.
Here are my questions:
Is the way I use for register my custom graphic class correct?
If not, what is the correct way to do that?
As something seems different since XE8, what it the new correct manner to register my graphic component?
Did anyone else faced the same issue? How he resolved it?
Is this may be a new RAD Studio bug, or the issue is rather on my side?
This is most likely a side effect of the smart loading the IDE applies to design time packages. You can overwrite this behavior by calling ForceDemandLoadState(dlDisable) during the Register procedure of your package.
More about this can be found in the documentation of more recent versions of Delphi than XE8: Explicitly disabling smart loading of components in a design-time package

Alternative to TXMLDocument?

Recently we upgraded our code from Delphi 2009 to Delphi XE and updated our Indy components (not sure if this is relevant).
But ever since then we have had errors on Windows Server 2003 machines when loading and saving XML files.
XMLDoc.LoadFromFile()
XMLDoc.SaveToFile()
The DLL msvcrt.dll is much smaller on Windows Server 2003 (300kb or so) compared to over 600kb on other operating systems... So its missing something in that file and its causing the error...
Does anyone know how to fix this? Or is there an alternative to TXMLDocument that I can try?
By default, TXMLDocument/IXMLDocument is just a wrapper around the MSXML COM interfaces when running on Windows platforms. Neither TXMLDocument nor Indy use the _ftol2_sse() function, or even link to msvcrt.dll. Something else in your project is at fault.
msvcrt.dll is (part of) the Microsoft Visual C++ Runtime. I think you got an older (or maybe even newer) version of this runtime that doesn't include this function.
Now you'll have to find out where this function is called. Do you link obj files with your project or use (other) 3rd party dll's?
To answer the last part ("is there an alternative?"), you might want to check out Jedi Code Library's TJclSimpleXML class. It does not require any external DLL, is quite fast, and is very easy to use. Besides, these days JCL and JVCL are a must-have anyway if you code in Delphi.
http://wiki.delphi-jedi.org/wiki/JEDI_Code_Library is their page I believe. I hear in seattle you can get it through IDEs integrated package manager.

Converting Delphi 7 property editor to Delphi XE2

First of all, I have never written a property editor from scratch, but had some help with one in another question. Refer to the accepted answer there. This was in Delphi 7, and now I have started using XE2 and I have to make sure my property editor is compatible with both 7 and XE2.
It's essentially a collection editor, with the difference that each collection item has its own named component in the parent form. Is there anything new about the property editors in XE2 since 7, since it is a huge version jump?
I do NOT want to make a complete copy of my unit for different versions. I want to maintain all possible versions in one unit.
Edit
It appears that Delphi XE2 has the same property editors as Delphi 7, but the issue I was facing was that although I was including DesignIDE in my package, it could not find anything, so I had to add the ToolsAPI folder to my library path.
However, now I have a new issue after this.
[DCC Fatal Error] ToolsAPI.pas(18): F1026 File not found: 'DockForm.dcu'
I'm lost in the whole concept of BPL packages and requiring others, etc.
DesignIntf, DesignEditors, DesignMenus, DesignWindows are part of DesignIDE.bpl and is found in \Embarcadero\RAD_Studio\9.0\lib\win32\release\designide.dcp. But there is no designide.dcp for 64bit which is why it throws an error when compiling a 64bit package that references these units.
There is no 64bit version of DesignIDE because it is for a design time package and design time packages are 32 bit only (remember Delphi IDE is still only 32 bits). So always set your design time package as 32bit, not 64bit. :)
Mike
The DockForm.pas source code is available neither in Delphi XE nor in Delphi XE2.
You may try this accepted answer posted on SO applying to similar issue on Delphi 2010.
Presumably, it is compiled and included within some package already distributed with Delphi XE2.

Is it possible to debug a C++builder dll from Delphi if I have the dll sourcecode?

I have an application written in Delphi 7 which uses a c++ dll written in BCB 5.
I want to debug this dll from the Delphi IDE is this possible?
If it's possible which are the steps to debug?
As additional information I have the full source code of the dll.
It has been a while since I have dealt with C++ / Delphi together. But if I remember correctly, you can use the BCB IDE to run the Delphi application (compiled already) that uses your DLL. Basically, in your project settings in BCB, you can set a program to run when you click the "run" button, and I believe that you will be able to set breakpoints and stuff that will be caught when functions of your DLL are being called by that application. Still, this implies that you have BCB.
My recollection, and it's been a while since I last tried this, is that you need the C++ Builder IDE to do this.
It should be possible:
I have done it quite often to debug a BCB5 dll within the Delphi 6 IDE. My delphi 6 application uses the DLL and I can then step from the delphi code into the bcb code (and back). So I might work with Delphi 7 too.
Delphi isn't configured by default to do that. At that time I found an explanation on the web how to do it. Not sure, but it might have been the following page: http://www.delphifaq.com/faq/delphi/delphi_ide/f178.shtml
You will also need to compile the dll in debug mode and to indicate the path to the source code of the dll in the project options of your delphi application.

Resources