Graham Samuel wrote:
> Well, Richard, I am always very willing to believe that I’ve
> misunderstood something, but this is what happened (this material is
> extracted from conversations I had on this list in the middle of
> March).
>
> 1. I had an XML file - it was actually a .gpx file, which shows a
> geographical route as a series of waypoints. The ‘top level’ of
> this structure is ‘gpx’. I mean the first three lines are (watch
> for wordwrap):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <gpx xmlns="http://www.topografix.com/GPX/1/1"; creator="Geolives"
> version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.topografix.com/GPX/1/1
> http://www.topografix.com/GPX/1/1/gpx.xsd";>
> <metadata />
> <trk>
>
> 2. I converted it to an array using the function ConvertXMLToArray,
> by Trevor deVore - from Mike Doub’s Master Library.
>
> 3. I put the result into an array called ‘gGeneralArray’ - I can see
> this in the IDE as a nested structure.
>
> 4. I executed
>
> put the keys of gGeneralArray
>
> in the message box, and got the result
>
> gpx
>
> 5. I discussed this on the use-list, and Mike Bonner suggested
>
>> try
>> put the keys of gGeneralArray["gpx”]
>> and you'll get the next level of keys.
>
> 6. I did that and got
>
> wpt[1]
> trk
> @attributes
> wpt[4]
> wpt[2]
> metadata
> wpt[3]
>
> I just did this all again to prove to myself that I hadn’t made an
> obvious error.I am definitely only dealing with one array, so I can’t
> explain this, and the LC dictionary certainly doesn’t help.
>
> Tell me where I went wrong!
You're using other people's code so you're off the hook. :)
There does appear to be a problem there, but I'm not sure it's with
LiveCode, and even with the oddities in that example the "keys" function
appears to be working as designed.
The "keys" should return a list of all keys, even when the value of any
of them may be another array.
This is consistent with what you found: your array gGeneralArray
contain one element, and that element is another array. You can also
query the keys for the sub-array and obtain its keys, as you did.
Consider this much simpler example in which we have three keys, two of
which have values that are not arrays and one of which has an array for
its value:
on mouseUp
put "1" into tA[1]
put "2.1" into tA[2][1]
put "2.2" into tA[2][2]
put 3 into tA[3]
put the keys of tA
end mouseUp
In my Message Box I get:
3
1
2
...showing that all keys are accounted for, even tA[2] where the value
is another array.
So while the "keys" function seems to be fine here, your example above
has other interesting factors that make it somewhat curious, no doubt
contributing to the confusion here:
Nothing in the XML shown contains any of the elements shown in the
sub-array keys listing, so it's not possible to see how it was parsed
given what we have here.
Moreover, some of those sub-array keys appear to contain array notation
in in the name itself, which may be valid but is unusual and potentially
confusing.
Key names are pretty flexible, even more than the Dictionary entry
recommends, allowing (IIRC) pretty much any character other than NULLs
(and in v7 perhaps even NULLs are allowed).
So using "[" and "]" is as valid as part of a key name as any other
characters, but stylistically the choice is confusing, and unlikely the
actual name of the element as expressed in the source XML.
To figure out how you got the output you did I'd have to put together a
test stack after gathering up the relevant handlers from Master Library,
and given Trevor's characteristically excellent coding I'm sure the
final analysis would make sense of that example.
But for the moment, I think the key lesson here (if you'll pardon the
pun) is that sometimes stumbling across edge cases like this one can
lead one to think features are more intimidating or confusing than they
need to me.
Arrays in LiveCode are fairly straightforward name-value pairs, and
there's not even very much we can do with them: put, get, delete, and
obtain the keys. That's pretty much it.
If we stumble across an extremely uncommon case like the one you had the
misfortune to discover above, it may seem much more complicated than it
really is.
This is why I recommend experimentation on one's own to learn a specific
feature, like arrays. Get the basic operations down in an hour
experimenting on a throwaway stack, and then even confusing edge cases
like this one will become less daunting.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
