Page 1 of 1

datagrid reordering itself

Posted: Tue Jun 30, 2015 10:25 pm
by jalz
Hi Guys,

I have a form datagrid where I enter data. This data goes in fine. I then have a script which puts the contents of the datagrid into a array variable which then loops through the array to display the data outside of the datagrid. The only issue I have found is the order that the array is in doesn't match the order the datagrid is displaying the data on the card. Does anyone know how I can 'force' the array variable to contain the datagrid in the specific order the data is in.

Many thanks as always
Jalz

Code: Select all


// this is the code i use to capture the values in the datagrid
put the dgdata of grp "dggrid_lines" into tGrid


//this is the loop structure I am using, which spits the correct amount of data, but sometimes in a completely different order 

repeat for each key tIndex in tGrid

end repeat

Re: datagrid reordering itself

Posted: Wed Jul 01, 2015 1:06 am
by dunbarx
Hi.

Arrays in LC, however they are formed, are associative only, and do not reflect the order of the original data. No information is lost, but the array will not retain sorting or any other ordering.

Even if the data in the source is already sorted, the array will not be, (though usually close) and when changed to an ordinary variable, would have to be sorted in the clear to regain the original order.

If the data in the DG (or anywhere) is ordered a unique way, the array will not reflect that order directly. and must be restored to an ordinary variable and reconstituted. The methodology of such reconstitution has to be based on the original order.

So, do you really need an array? Extracting the DG data via the "dgText" will bring the information into the clear, and with the original schema intact. In other words, do you need the array particularly?

Craig Newman

Re: datagrid reordering itself

Posted: Thu Jul 02, 2015 9:09 pm
by jalz
Thanks Craig,

Never thought of using dgText, that may have saved me some time in the long run….
Just been walking through my array and the keys are stored in the correct order, i.e. record creation order. It seems the repeat for each key tIndex in tGrid where tIndex seems to start at 8, then goes to 9 and then to 6 …. so random.

I've solved the issue i have at hand by counting the array elements and doing a manual repeat like below. It seems to work desired, s will do further testing to see if I can use it going forward for my purposes or else look at converting to dgtext

Code: Select all

   repeat with i = 1 to 9
      answer tData[i]["Label 2"]
   end repeat
   
Jalz

Re: datagrid reordering itself

Posted: Fri Jul 03, 2015 7:23 pm
by phaworth
Try something like this:

Code: Select all

put the keys of tData into tKeys
sort tKeys numeric
repeat for each line rKey in tKeys
   --do whatever with tData[rKey]
end repeat

Re: datagrid reordering itself

Posted: Fri Jul 03, 2015 10:14 pm
by dunbarx
Phaworth's solution is sound, but might be considered a kluge within LC, in that it orders the keys of the array in the clear, and then addresses the array with that reconstituted data. Sort of a hybrid methodology, working both in and out of the array at the same time.

Nothing wrong with this sort of method. And there may be good reasons to use arrays in your project. I only am posting again to ask the same question, do you need an array?

Many new users jump right to arrays as if they were the standard foundational variable type, and it is often discovered that, thought there is nothing wrong with that per se, they are overkill for the task at hand. And they do have that "sorting" issue, whereas ordinary variables do not. I do use arrays, but never if an ordinary variable will do.

Craig

Re: datagrid reordering itself

Posted: Fri Jul 03, 2015 10:46 pm
by phaworth
I agree, dgText is perfectly fine unless there's a good reason not to use it like multiple lines, special characters, etc.

Not sure why what I suggested would be a kluge. I think it's a very common way of addressing the elements of an array when their keys are numeric, or at least I do it a lot :-)

Pete