xsharp.eu

Now we finally succeeded in letting our X# DLL contact MySQL databases from VO we also want to let the X# DLL retrieve the results of a query and pass it to the VO exe. Problem is that you can not exchange arrays like that. Also the existing array->string and string->array functions can not be use in any circumstances because they rely on a field separator character. Passing certain text or memo values could mean the separator could be misread.

I wrote a partial solution years ago, for exchanging via WCF. The X# program adds a memo field and just before the memo field we added a "pointer" telling how many bytes to expect instead of letting the code search for separator characters. But only for that memo field.

I think that would be a good technique for all fields. Something like this, the first 3 values are 5 characters long pointers etc:

#00002#00010#00020XXXXXXXXXXYYYYYYYYYYYYYYYYYYYY

meaning there are 00002 fields, one of 00010 characters (containing 10 x X) followed by one of 00020 characters (20 x Y), followed by the values from which the lengths are now known (the # can be omitted, added here for readability). Multiple records could look the same (until there's nothing left) and in the end we can pass a string which can be easily read into an array once received in VO.

Ok, not to much work to program this, but does anybody know of something like that isn't available in .Net already? Or know about a published method doing more or less what I write?

Dick

Dick,
I would certainly not create an array and also not invent your own transfer format but encode the data in xml like (assuming you are returning customers)
<customers>
<customer>...</customer>
<customer>...</customer>
</customers>
and then send the XML as string to VO.
In VO you can then use MsXml or another XML to parse the string and get the individual records.

Alternatively you could use json (this is less verbose).

Robert

We have also used XML and JSON to exchange array-like data between programs. The readability sometimes helps understanding errors. As you know the exact format the data arrives it isn't even necessary to use complex decodification. Instead it is possible to use some own string exchange and string2array-like functions (Of course nothing for purists).
Thinking XML and JSON like this means treating with field separators and escaping possible field separators by other characters.

Thanks Robert, Arne. Although it makes sense to use some existing technology rather than think out something myself, XML will fail for the same reason String2Array/Array2String will fail. It will only work if you can be sure about the kind of content being transferred.

Consider this:

<SomeRecord>
<Field1>Test</Field1>
<Field2>NL</Field2>
</SomeRecord>
<SomeRecord>
<Field1>This is some memo info in which I write something about </Field1></Field1>
<Field2>NL</Field2>
</SomeRecord>

If the second record, Field1, contains the bold content, like a memo field in which I describe how I use the XML function, where do you think the XML parser will think the second filed ends? Right, after the word "about" and not after the word "</Field1>" which logically is seen as the closing tag. Escape characters are the same problem. They work as long as you are not writing the value of the escape character.

A bit of searching shows me that JSON has the same problem. So unless I find some existing code which works (like a DBF with and without memos) also works I'll work out my original idea. It's the only way to store anything in the fields and get it sent 1:1 without escape codes and other tricks.

As a (off topic) personal note: the more I work with .Net, the more I find that most of the times a solution I expect I can solve with just using a standard property or method in the end can not be solved without a lot of programming. For example: this week I added so called watermark, which is a message usually in light gray giving some explanation of what to fill in. As soon as you enter the textbox the content should disappear and the user must continue in the default font colour. And when the field would be emptied, the explanation should re-appear. To my surprise Microsoft MSDN solution was based on doing that with a .gif file (https://docs.microsoft.com/en-us/dotnet ... -a-textbox)! This is very impractical, and even more in multi lingual programs. In the end I solved it with just 1 few lines of code in 2 methods, but I would expect this to work with just defining the content (depending on the language) as a property of the textbox. But there isn't any.

Dick

Hi Dick,

Not sure if you have it, but have you looked at my jhnIniFile class, maybe that could give you a hint. Let me know if you have it or need maybe more information. I am sure it can easily be converted to what you are looking for.

HTH,

Dick,

In that case you should not store the memo as text in the XML but in a CDATA block.
In your code you could check to see if the memo contains a "<" or ">" character and when it does, then you need to wrap it.
See https://en.wikipedia.org/wiki/CDATA

Robert

Hello Robert, Johan,

Thanks for the hints.
We don't have good experiences with parsing XML. We had a function based on MSXML.DOMDocument, and learned (the hard way) that

oXMLNodeObj:=oXML:documentElement:selectNodes(cNode)
cResult:=oXML:GetElementsByTagName(cTag):item(0):NodeTypedValue // Get value


simply didn't work: it ignored the cNode value passed. We wrote a temporary workaround.

Currently we give it one more chance by exploring Chilkat's XML methods. If that works it is probably the most general and fastest (yet readable) way to solve this. But I think that by definition no method, including CDATA blocks, is full proof: add the exact value of any content trying to prevent < or > characters to be interpreted as text, and this exact value including CNAME will be seen as a closing tag where it isn't.

If Chilkat's library doesn't work well either I will send the "pointer based" . I may ask you Johan for the jhnIniFile class to be compared to existing pointer based code we have (but this only creates one large query with 1 pointer string as return value for WCF)

Dick

Dick,

ic2 wrote: oXMLNodeObj:=oXML:documentElement:selectNodes(cNode)
cResult:=oXML:GetElementsByTagName(cTag):item(0):NodeTypedValue // Get value

simply didn't work: it ignored the cNode value passed. We wrote a temporary workaround.

Did you pass in the node name or an XPath query ?
selectNodes() expects an XPath query.

Robert

Hello Robert,

[quote="robert",
Did you pass in the node name or an XPath query ?
selectNodes() expects an XPath query.
[/quote]

I passed a string, which is as, I believe, documented by Microsoft

https://docs.microsoft.com/en-us/dotnet ... etcore-3.1

I think it was as follows:

cResult:=XMLParser("MyXMLFile.xml","delivery","name") didn't give the delivery name in the xml below, but the sender name, the first <name> tag.
...
oXMLNodeObj:=oXML:documentElement:selectNodes(cNode)
cResult:=oXML:GetElementsByTagName(cTag):item(0):NodeTypedValue
...

After some trial without the expected results we solved it for now with an At3 based method. Hopefully the Chilkat solution works without problems.

<sender>
<name><![CDATA[Sender name]]></name>
</sender>
<delivery>
<name><![CDATA[Delivery name]]></name>
</delivery>

Dick