LiveCode Forums.

The parameter passed to revStartXmlNode is the value of the "address" function (ie: the host system) when the parameter should actually contain the string "Address".

Thus, XML files containing Name, Address, Occupation, etc. don't work properly.

I put in an "if pParm = address then pParm = "Address" to get it to work "right". This may or may not have problems with other strings that match keywords.

The parameter passed to revEndXmlNode is correct -- ie: the string "Address". revStartXMLData passes the correct data.

Also, the "messages" that are sent from revCreateXMLTree and revCreateXMLTreeFromFile are not necessarily sent to the card where those functions are called from. It took me quite a while to figure that out. I created the tree from card #4. Perhaps it goes to card #1? Unknown at this time. I moved all my script functionality to the stack that contains the card(s), and it worked fine. It's undesirable to separate the script from the card, but it's functional.

I would like a way to cancel the processing of the file. Currently, if I have 10,000 nodes containing customer info, and I find what I need after node #23, I don't have a way to stop the reading/processing the file. It takes a lot of time to ignore all the rest of that data. Yes, I could build a tree and access the data from the tree, but I would still be processing way too many records for my needs. I don't know how this would be implemented, other than perhaps yet another (optional) parameter to the revCreateXMLTree functions that provides a variable to set that would inform the processor to stop processing. Or, a global? Ugh.

You might have better luck with libSTSxml - Ken Ray just released a new version - find out more at http://www.sonsothunder.com/products/xmllib/xmllib.htm

Hope this helped,

Jan Schenkel.

Thanks, but that doesn't help. Been there, considered that.

I need the revCreateXmlTreeFromFile functionality, with a way to cancel it on my command.

Why? Because I'm processing a 645KB file (it could vary significantly in size), so for performance reasons I would prefer the compiled "C" code over Rev scripts.

This forum also serves as notification to others who might be suffering the same problem as I did with the "Address" glitch, and the messages being sent to someplace other than the card where the revCreateXmlTreeFromFile was executed.

I find it interesting that often times the replies to a suggestion and/or reported bug on this forum point the user to someplace other than Revolution. That doesn't say much for Revolution, does it?

Whatever, thanks for the suggestion.

TEDennis wrote:The parameter passed to revStartXmlNode is the value of the "address" function (ie: the host system) when the parameter should actually contain the string "Address".

Thus, XML files containing Name, Address, Occupation, etc. don't work properly.

I put in an "if pParm = address then pParm = "Address" to get it to work "right". This may or may not have problems with other strings that match keywords.

The parameter passed to revEndXmlNode is correct -- ie: the string "Address". revStartXMLData passes the correct data.

Hi,

Can you post some example code to better illustrate the problem you are having? I just tried parsing the following xml:
and the values that came through were:

name,bob
address,1640
occupation,test

which are the correct values.

In regards to message targeting - I placed this script in a button on card 4 of a test stack:
and then
in the card script. The revStartXMLNode message was sent to the card as explained in the docs. Can you describe how your code is structured?

By the way, I was testing with Revolution 2.9 on OS X.

Trevore: I'm using Rev 2.9.0 on WinXP

Following is a copy/pasted node, with the actual data values munged:

<Customer>
<CustomerName>Elmer Fudd</CustomerName>
<Address>1111 1st Street</Address>
<City>Somewhere</City>
<State>AK</State>
<PostalCode>88222</PostalCode>
</Customer>

The parm to "revStartXmlNode" when the nodename *should be* "Address" is "MYNAME:C:/Program Files/Revolution Studio/2.9.0-gm-1/Revolution.exe" -- which is the same as I get when I say "Put the address" in the message box.

Following is a portion of the Script for button "Search":

put revCreateXMLTreeFromFile(tXmlFileName,true,false,true) into tXmlResult
if tXmlResult is not a number then
showErr "Error processing XML file:" && tXmlFileName && the result
end if

I have one main stack and two substacks. The "Search" button is in the mainstack in card #3 (sorry, I said #4 before). With the message handlers in the same card, I put a breakpoint on the revCreateXMLTreeFromFile, run to the breakpoint, then do a "Step". It gets lost. It apparently stops *somewhere*, but I don't know where. If I put a breakpoint in EACH of the message handlers, none of them stop. If I move all those message handlers to the main stack, they work fine. This part of the problem *could* be "simply" a glitch in the debug script display. Whatever, it took me quite a while to figure out that moving them to the main stack "fixed" the problem.

Thanks for offering to help.

I've confirmed the bug when parsing a node with a Revolution property name. I filed a bug report on it: <http://quality.runrev.com/qacenter/show_bug.cgi?id=6512>.

I haven't been able to replicate any message issues. It is possible that the debugger is getting in the way. I use the GLX2 debugger which doesn't seem to have any problems. If you download the example stack from the bug report you could try putting a breakpoint in the card script and see if it works or not.

Yep, the debugger goes nuts. Put a breakpoint on the revCreateXmlTree, then click "Run Test". The debugger stops as expected on the revCreateXmlTree statement. Do a "Step", and it stops in weird places. For instance, it stops on the "--> All handlers" comment in the stack script. Step again, and it advances to the blank line following that comment.

I suspect that this is a Debug problem common to all DLLs that have callbacks.

Thanks for verifying the "Address" problem.

Anybody know how to kill an external command without getting myself in deep doo-doo? I'm tempted to "EXIT TO TOP" from one of the callbacks when I find the entry I'm looking for. But, I don't know what environmental gotchas I will be setting myself up for if I do that. I doubt the revCreateXmlTreeFromFile function will know enough to close the file, etc.

I'm not aware of any way to cancel the xml tree parsing. You are basically looking for a call similar to revZipCancel that can be called from within a callback. I would file an enhancement request in the Quality Control Center. Who knows, maybe it will be trivial to implement and you will see it in the next release.

I ran into a similar problem; this time with revStartXMLData

It appears that text between the revStartXMLData start and end tags is being evaluated, too.

The Rev "REPLACE" command replaces one string with another. So, "replace ABC with DEF" yields "DEF"

An ampersand is a synonym for "replace".

If the text of a given node is "Sanford & Sons", the data passed to the script is "SONS" -- apparently because "SANFORD" replaced with "SONS" yields "SONS"

I can circumvent the "Address as a node name" glitch as I stated earlier in this thread, but this one is a show stopper unless somebody can figure out a way to circumvent it.

It seems to me that this problem, especially the one where REV keywords are used as tag names (like the commonly used "ADDRESS"), should have been encountered many times in the past. Since this is the first report of those problems, does that mean the revXml support hasn't been used by many people? Or does it mean the revXml support was used and is currently producing bogus data that nobody has realized yet is bogus? Or, did people try to use the revXml support, found the bugs and couldn't figure out a way around them, and decided to avoid revXml support? In any case, it seems this should be a high priority bug to be fixed.

What you are seeing most likely has to do with how the revXML external is sending the messages. There are a couple of ways to go about sending parameters to functions from externals and the method that revXML is using is evaluating the variable in the external that is being passed as a parameter to revStartXMLData as an expression rather than just sending the value. It should be an easy enough fix.

I imagine most people aren't using messaging with revXML but rather creating trees which is why the bug hasn't been reported. I use revXML quite a bit but always with trees since I don't work with large XML trees.