Datagrid problem

[CAsba]

Hi,
I have a backup field, 'dgtextstore', into which I set the dgtext of group datagrid 3. This is done prior to the operation.

Code: Select all

 set the text of fld "dgtextstore" of cd "manage products" to the dgtext of grp "datagrid 3" of cd "manage products" 

This is to enable the user to Cancel the operation at any time; any data entered into the DG will be removed by the Cancel instruction
returning the DG to its pre-operation configuration

Code: Select all

 set the dgtext of grp "datagrid 3" of cd "manage products" to the text of fld "dgtextstore" of cd "manage products"

The problem is that the second part of the code shown works sometimes - sometimes it fails. It works when there is one (only) line change, meaning that there is one more line in dgtextstore than in DG3; when there is more than 1 line change it doesn't work ( this occurs when a manufactured product has a list of components, each having a line).
Any ideas how to rectify this ?

[SparkOut]

At a guess, and this is only a guess, it could be the text including extra line breaks, if there are descriptions on multiple lines with return characters within the field, this will "break" the data structure.
Does the same problem occur if you use a custom property to store the backup using the dgData (as an array) instead of a field storing dgText?

[stam]

It may depend on what is in the text; if there are line separators (ie CR/LF) in the dgText you are exporting to a field, this will fail for sure.
It is better to store as an array (so line/record delimiters don't interfere) and can easily be done in a custom prop of the datagrid itself.

ie:

Code: Select all

set the uData of grp "datagrid 3" to the dgData of grp "datagrid 3"

and

Code: Select all

set the dgData of grp "datagrid 3" to the uData of grp "datagrid 3"

[dunbarx]

Sparkout.

Interesting idea on the possibility of errant line breaks, but could any possible such breaks cause the issue? In other words, if the DG was already in a stable condition, how could taking the dgText out and then putting it right back in matter?

Anyway, given a DG with, say:

Code: Select all

aa (tab) bb (tab) cc
dd
ee
ff
gg (tab) hh (tab) kk

The DG simply contains tab and return delimited data. Returns are handled naturally however the DG is populated, a total of five rows in the above example. The dgData ought to work the same. I do not think it should matter how the data is stored, in a field or in a custom property.

It is not like Excel, where one can visually place return delimited text within a single "row". But even Excel keeps the returns and tabs correctly, even though it displays them differently.

But if CAsba is correct that a single row never fails, then I am at a loss..

Craig

[dunbarx]

Sparkout.

if there are line separators (ie CR/LF) in the dgText you are exporting to a field, this will fail for sure.

I do not see this. If I have a new DG with some multi-row data in it, and:

Code: Select all

put the dgtext of grp "dataGrid 1" into fld "ff"

I get a perfectly formatted and populated field "ff'.

Perhaps I do not understand what you meant by "line separators'?

Craig

[SparkOut]

I guess I was fixated on the "typical" problem of data formatting and blinded myself to the source being the datagrid in the first place.
I am still curious whether the dgData in an array might behave any differently - I suspect faster than text in a field anyway.

[dunbarx]

I am still curious whether the dgData in an array might behave any differently

I use arrays, probably much less than others do, but do not think that there could be any difference when one finally extracts array variable data into a "usable" form. Arrays are very useful because of the compact and powerful way one can access and interact with a dataset. But the underlying structure of that dataset has to be inviolable.

I think.

Craig

[SparkOut]

It was the stuffing into and pulling out of a field that I thought would be the slowdown. Not that it's likely to be noticeable even so.

[CAsba]

Thanks all, for your input. The issue is resolved - I built a new datagrid !

[dunbarx]

CAsba.

Did you simply replace the contents of the new DG with that of the original? Or did you populate it by other means? Your answer may shed light on the original issue.

Craig

[CAsba]

Hi Craig,
I copied the 'backup' field data to the DG.
Unfortunately, the solution only lasted for the one backup; it then reverted to the original problem.
I'm still stabbing in the dark, hoping a lasting solution comes up.

[CAsba]

A possibility occurred to me that the problem may involve the DG being siorted on the code column. I may have to return the dg to the default, update the DG, then revert back to sorted by code. Can anyone advise me of the script to sort by index ?

[CAsba]

Hi,
Now it's really solved. I set the sort to Empty

Code: Select all

 set the dgProps["sort by column"] of group "datagrid 3" to empty

I originally changed the sort to 'Type' as an enabler for the user, when choosing from what could be a long list of components of an assembly (and so, unknowingly, setting myself up with a problem that's taken a week to resolve!)
I'll have to experiment in changing ftrom 'empty' to 'type' in the various parts of the process.
Thanks all of you for your kind interest.

[stam]

Just some comments:

• The internal data type for the DG is array.
• The text version of this (dgText) is a derived convenience.
• For operations where you are simply moving the data around it's always safest to use array format (dgData).
• The sort order does not affect dgData.
• dgText is in TSV format - so anything that breaks the TSV format (eg tabs or returns within a cell) will break dgText as well - so use dgData instead.
• If you want to inspect the internal array (source data), look at the custom props of the group and select "dgCache" from the dropdown. You'll see the array source data there a tree view and the sort order of these as a separate field... always useful to be familiar with this in the property inspector.