Ralph: The first index is the integer 1, not the string representing the integer 1. So, it is probably an improper way to set an element of an array. Was my bad. Best, Bill
> On May 4, 2015, at 11:51 AM, Ralph DiMola <rdim...@evergreeninfo.net> wrote: > > Shouldn’t myArray[“i”][“name”] be myArray[i][“name”] ? Otherwise all the data > would be put into array key "i" instead of the value of "i". > > Ralph DiMola > IT Director > Evergreen Information Services > rdim...@evergreeninfo.net > > -----Original Message----- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf > Of William Prothero > Sent: Monday, May 04, 2015 2:43 PM > To: Use-livecode Use-livecode > Subject: Re: LC7 arrayEncode/Decode > > Richard: > You may be right about inconsistent formatting in the array. > I started the array with: > put myVal into myArray[1][“name”] > Then later do: > put myNextVa; into myArray[“i”][“name”], where i is an index in a repeat loop > So, one would have an integer and the others would be a string of an integer. > > I did the fix and it worked fine. > Still a bug? Seems it should still return the original array. > Best, > Bill > >> On May 3, 2015, at 2:39 PM, Richard Gaskin <ambassa...@fourthworld.com> >> wrote: >> >> William Prothero wrote: >> >>> I found an oddity with arrayEncode and arrayDecode, When I saved an >>> array to a file, first using arrayEncode(myArray), wrote it out as >>> >>> put arrayEncode(myArray) into theEncodedArray put theEncodedArray >>> into URL(“binfile:”&myfile) >>> >>> and then read it back in using >>> put URL(“binfile:”&myFile) into theEncodedArray put >>> arrayDecode(theEncodedArray) into myArray >>> >>> myArray has the first element as a blank entry. It’s not the same >>> array as I started with. >>> >>> My array looks like myArray[1][“name”], myArray[2][“name”], etc >>> >>> This seems like a bug to me. I didn’t get any satisfaction when I >>> set the storage method as text, but then again, I couldn’t find a >>> lesson where that format was specified. But, it seems like whether >>> it’s binary or not, it should still read back in and decode correctly. >> >> It might be a bug, but like many here I do a LOT of work with arrays, and >> with so much user testing, combined with that part of the engine's code base >> being somewhat isolated, I'd double-check the recipe first before submitting >> a bug report. >> >> Unexpected keys can sometimes arise from running split on data that's >> inconsistently formatted. >> >> How is the array created? >> >> -- >> 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 _______________________________________________ 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
