EldoS | Feel safer!

Software components for data protection, secure storage and transfer

XMLBlackbox. Is this bug?

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
#15423
Posted: 01/05/2011 12:54:57
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

XMLBlackbox VCL version 8.1.191. I wonder if these are bugs or not.

Code
procedure TForm1.Button1Click(Sender: TObject);
var
  aDoc: TElXMLDOMDocument;
  aElement: ElXMLDOMElement;
  F: TFileStream;
begin
  aDoc := TElXMLDOMDocument.Create;
  aElement := aDoc.CreateElement('MainId');
  aElement.InnerXML := '345';
  aDoc.AppendChild(aElement);
  F := TFileStream.Create('Test.xml', fmCreate);
  aDoc.SaveToStream(F, xcmNone, 'utf-8');
  aDoc.Free;
  F.Free;
end;

That creates this XML output as expected:
Code
<?xml version="1.0" encoding="utf-8"?>
<MainId>345</MainId>

Then I try to add one character long data:
aElement.InnerXML := '3';
Code
<?xml version="1.0" encoding="utf-8"?>
<MainId/>

I only got an empty XML. To me it looks like XMLBlackbox would not allow one character long values at all.

---
Also, I would like to know what is the difference between InnerXML and NodeValue. If I try to use NodeValue to put the value in:
Code
aElement.NodeValue := '345';

I again do not get anything, even though I have longer data value than 1 chars, I only get an empty Node.

The Online Help says like I could use NodeValue for this purpose also.
"NodeValue = This property gets or sets the value of the node."

I do find how to use NodeValue.

Thanks.
SP
#15424
Posted: 01/05/2011 15:50:48
by Ken Ivanov (EldoS Corp.)

Thank you for contacting us. It seems that there really is a problem with assignment of 1-character values to the InnerXML property. We are investigating the problem at the moment.

Generally, NodeValue property should not be used as a replacement for InnerXML. Assigning values with the use of the former only makes sense for some types of nodes (in particular, TElXMLDOMAttr and TElXMLDOMEntityReference).
#15425
Posted: 01/05/2011 16:32:20
by Ken Ivanov (EldoS Corp.)

The issue has been localised and fixed. The fix will go to the future build update which we plan to make available within few days.

If you are compiling SBB from source code, we can also provide you with a quick code fix. Just let us know.
#15426
Posted: 01/06/2011 05:40:27
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Quote
Innokentiy Ivanov wrote:
Generally, NodeValue property should not be used as a replacement for InnerXML.
Thanks. In Delphi Value is used in so many places to store the data values, also the current XMLBlackBox Help says Value would work here in the same way. It took ages for me to find that Value is not the way, but you have to use InnerXML to set XML Node values.

So some mentioning about this in online Help would be quite useful info.
Quote
If you are compiling SBB from source code, we can also provide you with a quick code fix. Just let us know.
We have purchased the licence in November 2010. I do not know how long we are entitled for these corrections and updates. So please, put the correction source lines somewhere where I can get it.

I wonder if this affects also to XML files having 1 char long Node values, and XML/SOAP signings? I'm still having difficulties in there. But I'll post to another thread about these.
Thanks.
SP
#15427
Posted: 01/06/2011 09:01:30
by Ken Ivanov (EldoS Corp.)

Thank you for pointing us at that ambiguity. We will update the documentation to make it clear in this regard.

Your license gives you free upgrades to all upcoming SecureBlackbox 8 builds, and also free upgrades to all SecureBlackbox 9 builds. SBB 9 is going to be released later this year. Please do the following to apply the fix:
1. Open SBXMLCore.pas unit in Delphi IDE,
2. Find the implementation of TElXMLDOMElement.ParseInnerXMLFromStream method,
3. Add the following lines to the very beginning of the method's implementation:
Code
  if (Parser.sEOF) and (Parser.fLast <> '') then
  begin
    p := Parser.LastPos;
    n := fOwnerDocument.CreateTextNode('');
    AppendChild(n);
    Parser.sPos := p;
    Parser.NextChar;
    n.SafeParseFromStream(Mode, false);
  end;


Quote
I wonder if this affects also to XML files having 1 char long Node values, and XML/SOAP signings? I'm still having difficulties in there. But I'll post to another thread about these.

No, only assignments to the InnerXML property were affected by the issue. So your problem XML/SOAP problem might have a different reason. Could you please let us know about it?
#15445
Posted: 01/10/2011 04:18:43
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Thanks, that fixed the 1 char long value problem. I did some confirming tests after this fix and faced another problem. Yet it probably has nothing to do with this fix.
I had earlier thought this BOM problem was fiexed with me, as I had added the correcting code snippet from these newsgroups. But now I found my test editor had just hidden the BOM, and the chars actually are still there.

Code
procedure TForm2.Button1Click(Sender: TObject);
var
  aDoc: TElXMLDOMDocument;
  aElement: ElXMLDOMElement;
  F: TFileStream;
  Codec : TElXMLCodec;
begin
  aDoc := TElXMLDOMDocument.Create;
  aElement := aDoc.CreateElement('MainId');
  aElement.InnerXML := '345';
  aDoc.AppendChild(aElement);
  F := TFileStream.Create('Test.xml', fmCreate);
  Codec := TElXMLUTF8Codec.Create; // Use this trick to avoid BOM be written.
  aDoc.SaveToStream(F, xcmNone, 'utf-8'); // This works, but with BOM.
  aDoc.SaveToStream(F, xcmNone, Codec);   // This creates XML, but 0 bytes.
  aDoc.Free;
  F.Free;
  Codec.Free;
end;

I have tried several other options also, like
Code
Codec := TElXMLUTF8Codec.Create(F);
but these do not bring any better results.

Quote
So your problem XML/SOAP problem might have a different reason. Could you please let us know about it?
I was in process trying to write an example to demonstrate that. Having BOM in SOAP probably should not prevent Signing to work right. But I'm not quite sure about it, and would like to close this BOM possibility out.

Thanks.
SP
#15446
Posted: 01/10/2011 05:15:05
by Vsevolod Ievgiienko (EldoS Corp.)

Hello.

Try to rewrite your code like this:
Code
  aDoc := TElXMLDOMDocument.Create;
  aElement := aDoc.CreateElement('MainId');
  aElement.InnerXML := '345';
  aDoc.AppendChild(aElement);
  F := TFileStream.Create('Test.xml', fmCreate);
  Codec := TElXMLUTF8Codec.Create; // Use this trick to avoid BOM be written.
  Codec.WriteBOM := false;
  aDoc.SaveToStream(F, xcmNone, codec);  
  FreeAndNil(aDoc);
  FreeAndNil(codec);
#15447
Posted: 01/10/2011 09:20:35
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Code
Codec.WriteBOM := false;
All right. I had forgotten that important line from my previous sample. Originally I had written simple procedre when I wanted to continuously save files without BOM.
I hastily took those lines from this original Procedure:

Code
procedure TForm1.SaveWithoutBom(aDoc:TElXMLDOMDocument; XmlFN:String);
var
  F: TFileStream;
  Codec : TElXMLCodec;
begin
  F := TFileStream.Create(XmlFN, fmCreate or fmOpenWrite);
  Codec := TElXMLUTF8Codec.Create;
  try
    Codec.WriteBOM := False; // Prevent BOM
    aDoc.SaveToStream(F, xcmNone, Codec);
  finally
    FreeAndNil(F);
    FreeAndNil(Codec);
  end;
end;

procedure TForm1.btnTest1Click(Sender: TObject);
var
  aDoc: TElXMLDOMDocument;
  aElement: ElXMLDOMElement;
begin
  aDoc := TElXMLDOMDocument.Create;
  aElement := aDoc.CreateElement('MainId');
  aElement.InnerXML := '345';
  aDoc.AppendChild(aElement);
  SaveWithoutBom(aDoc, 'Test.xml');
  FreeAndNil(aDoc);
end;

This code keeps giving me Access Violation when I use Codec:
Code
aDoc.SaveToStream(F, xcmNone, Codec);
If I write without Codec this works all right.
Code
aDoc.SaveToStream(F, xcmNone, 'utf-8');


There's something why Codec would not like to do it's job in a separate Function, but I have not found what that is.

Thanks
SP
#15448
Posted: 01/10/2011 09:29:25
by Vsevolod Ievgiienko (EldoS Corp.)

Try to remove FreeAndNil(F); line from SaveWithoutBom and check if Access Violation occures again.
#15449
Posted: 01/10/2011 10:43:20
by San P (Standard support level)
Joined: 11/07/2009
Posts: 37

Quote
Vsevolod Ievgiienko wrote:
Try to remove FreeAndNil(F); line from SaveWithoutBom and check if Access Violation occures again.
If I do not Free F at all, then the Test.XML file will stay (write)locked as long as my App is active.
Also the AV does not go away with taking that line off, as it gets raised exactly on this line:
Code
FreeAndNil(Codec);
If I comment also this Codec freeing line out, so never free the Codec, then the output XML file will be empty, 0 bytes long.

I can no find what is the difference that makes this AV to appear when using Codec this way in simple separate Procedure, or alternatively use it in the apps main body.

Thanks
SP
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 3551 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!