Specifically, if msxml 4 is not present on the system, and msxml 6 is present, will the Delphi msxml component (in Delphi 2006) use msxml 6?
Q: Why don't you try it?
I presume you mean the Delphi class TXmlDocument and friends. It "expects" MSXML 4 ... but the VCL checks dynamically:
https://delphihaven.wordpress.com/2010/03/07/using-msxml6/
By default, the VCL’s TXMLDocument class will delegate to MSXML for
its actual parsing and writing. Now MSXML itself comes in various
versions, with newer ones being installed side-by-side with older
ones. To cope with this situation, the VCL tests for the existence of
a number of them, the idea being to prefer whatever MSXML version was
current when the unit in question (MSXMLDOM.pas) was last updated.
The same link also discusses how to select a "preferred" MSXML version if you wish.
STRONG SUGGESTION: Compile your Delphi .exe or .dll and test it on a "clean machine" (presumably a PC with only MSXML 6 installed) and observe the behavior.
It is not possible to test on a machine with only msxml6, because even Windows10 installs out of box with msxml3 and msxml6 present.
Related
I have a program written in Delphi 6 that uses TXMLDocument, and during runtime it uses the MS XML 3.0 parser. But this program reports a The specified module could not be found error on one computer, and Process Monitor reports that the program is trying to access MS XML 4.0 modules and registry keys. This 4.0 installation is incomplete/corrupted and that is why the access fails with The specified module could not be found.
So, the core issue is some mechanism/decision algorithm that diverts TXMLDocument from using the standard MS XML 3.0 or MS XML 6.0 versions that are on all the current Windows 10 machine, and that presses TXMLDocument to use MS XML 4.0 version. What is this decision mechanism in TXMLDocument and how to correct it?
Of course, I can find, download, and install MS XML 4.0 on the client computer, but this seems to not be the correct solution.
There is no secret magic here. It is well known what mechanism is used. You can see the source code for yourself in Delphi's msxmldom.pas file.
When TXMLDocument uses the MSXML DOMVendor on Windows, it simply calls CoCreateInstance() in a loop to attempt to instantiate a hard coded list of different versions of MSXML's IXMLDOMDocument COM object, in decreasing order of version, until one version finally succeeds, or they all fail.
MSXML 6.0 did not exist yet when Delphi 6 was released, so it is not a version that is attempted. And you said MSXML 4.0 is broken on your customer's system. So it makes sense why MSXML 3.0 ends up being used instead.
Have a look at the following question for how to make TXMLDocument use MSXML 6.0 in such an old Delphi version:
How to create a TXML Document using MSXML 6.0 in Delphi 7?
Is there any information on the project file, source code and *.dfm file compatibility between the different DELPHI versions.
If I do not use the latest features of DELPHi XE3 can I still open the code base and compile using eg. DELPHI 2010 ?
( I Know Unicode Issues, or Component changes like INDY 9 to INDY 10 will block the down grading , but this an other topic for me)
The bad think e.g. not working : use your Delphi 7 project, open and compile using DELPHI 2010, you can not reopen the project with DELPHi 7 because some objects will have extened properties from opening the project with 2010. Manual rework back to DELPHi 7 style in that case is rather time consuming.
Can a developer team work together, were members are using different DELPHI XX versions?
It's possible to do what you want but I cannot imagine why you would want to. When we ported our app from D6 to D2010 we had shared source that would build in both versions.
This was purely a transitional arrangement. As soon as we were confident in the D2010 port, we severed the umbilical cord. And at this point we embraced the new features of D2010 with relish.
In order to make this work we used the following crutches:
Helper functions to mitigate the ANSI/Unicode differences.
Unit aliases to deal with unit renaming. For example the themes units changed names from D6 to D2010 and the unit alias feature hid that.
Oodles of conditional code.
All this was needed because we had a porting task and so had to compile in both versions. The old version for our existing product maintenance, and the new version so that we could test and develop the port.
But I see no reason for you to do any of this., not least because it leads to very complex code. If you want your app to build in D7 then always build it in D7. Since you cannot use features of modern Delphi and retain compatibility with D7, why use anything other than D7? When you buy modern Delphi you also gain access to old Delphi versions.
What is the best (easy to use, performances) library to manage XML on Delphi XE2. Windows and Mac targets in mind.
I usually go for the NativeXML library, it's an XML library completely written in Delphi code and it's free. I'm not sure if the latest version offers compatibility with the Firemonkey platform, but with a few changes to unit names I tested it successfully back when Delphi XE2 was first released.
You can find the component here: http://www.simdesign.nl/xml.html
In case the latest version isn't compatible with XE2 yet, there's a topic on the forums about how to make it compatible: http://www.simdesign.nl/forum/viewtopic.php?t=2110
You can use OmniXML, it is:
100% written in delphi
Has no outer dependencies
Works on XE2, did not test it on OSX
On top of OmniXML you can use SimpleStorage to give you more power and simplicity managing the XML.
Andreano Lanusse has a nice blog post on using XML on Mac. It turns out that:
When you drop a TXMLDocument component on your design the default DOMVendor MSXML, you have to change to ADOM XML v4 to support cross-platform.
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.
Okay -- we have an interesting problem.
Some background:
Our main application uses Indy 10. However, we take the Indy 10
source and fix bugs in it, recompile, and install our own set of Indy
components.
We are migrating to Delphi XE and want to start using DataSnap.
DataSnap requires the "official, shipping" version of Indy which is
incompatible with our customized version of Indy.
Our DataSnap servers will be separate applications, but since we
have our own Indy installed in the IDE, we can't "cross the streams".
Okay, therefore, we are unable to use Delphi XE's DataSnap out of the
box because of this compatibility issue.
So my questions is this:
Is it possible to recompile the DataSnap packages in Delphi XE with a new/different version of Indy?
Your thoughts gratefully accepted.
The common belief is No, that's not possible due to not all sources being provided by Embarcadero and some of these sources are reliant on the build of Indy as shipped. (Which is extremely frustrating to end users as the version of Indy that ships with Delphi is out of date relatively quickly and sometimes the version selected at the time is not necessarily a very good one.)
See related SO question:
Is it possible to use Indy 10.5.8.0 in Delphi XE and DataSnap?
Also see the Indy project page:
http://www.indyproject.org/Sockets/Docs/indy10Installation.de.aspx
which states:
Note: In D/CB/RAD 2009+, DataSnap uses
Indy 10 internally. Installing a new
version of Indy will render DataSnap
unusable, as it will not be able to
load the Indy packages anymore.
DataSnap is compiled against the Indy
packages that ship with the IDE, and
DataSnap cannot be recompiled by end
users. If you need to use DataSnap,
then you will need to maintain the
original Indy 10 packages for use in
DataSnap projects.
It's been said that the next version should hopefully allow for easier updates of Indy.
If all DataSnap source is included, is of course possible using some kind of PE executable analisys program to detect which classes and units are used in BPL (as BPLs are just customized DLLs). An very easy one to use is provided with GExperts.
In BPLs, the exports list lines from GExperts\PE Information have an format like #xp$#[nn][UnitName]#[TypeName] (for types) and #[UnitName]{#[Type>]}#[Unit global element like procedures or variables] (for the rest).
You can save that list to a file and GREP to get an list of Units used on a BPL.
Real Examples (vcl140.bpl):
#$xp$11Forms#TForm
#Appevnts#TCustomApplicationEvents#Activate
#Clipbrd#Clipboard