Just reencountered very early OI problem I'd forgotten.

Using SET_PROPERTY(EditTableName,'DEFPROP',ColData,Col) with @VM-delimited ColData, I find it only writes the first element and loses the rest of the ColData. I've tried ot with Col as just the ColNo, as ColNo:@FM and as ColNo:@fm:0 and it's the same all ways.

ColData=GET_PROPERTY(EditTableName,'DEFPROP',Col) works fine and gets a full @vm-delimited result.

Anyone else having succss or problems using DEFPROP in this way to set_property an edit table column?

Is this a bug or have I missed something?

Richard,

Try @FM-delimited data.

- Oystein -

Oysten

Many thanks indeed.

It would seem logical to send the column data @vm-delimited as :-

1) I think I saw during testing that Get_Property(EditTable,'DEFPROP',Col) returns the data @vm-delimited

2) If one uses DEFPROP for the table as a whole, one gets ARRAY in which the columns are @fm-delimited but the data within each column is @vm-delimited

3) The COLDATA property returns the data @vm-delimited

4) The online manual says nothing about delimiters and, in the light of the above, it would seem therefore logical to send the data @vm-delimited.

Now we know!

It's down to whether DEFPROP is ARRAY or LIST fwiw.

The Sprezzatura Group

World Leaders in all things RevSoft

Since last posting, done a little test…

Altered my routine to set-prop and immediately get-prop edit table DEFPROP for col into different variables three times and then debug: first time @fm-delimited, then @vm-delimited and then (for fun) @svm-delimited. Three calls from different edit tables :

1) Table 1 Col2. Wrote and read correctly whether @fm- or @vm-delimited

2) Table 2 Col1. Just wrote & returned first element, losing the rest.

3) Table 2 Col2. As table 1 Col1.

@svm delimited not surprisingly treated as single cell and therefore irrelevant.

What do you make of that, folks??

Richard,

When I read your first posting I thought I had a reason to suspect a @VM/@FM mix-up. So I tested with @FM and it worked. And I posted my reply, suggesting you switched to @FM. Now when I try with either @VM or @FM or even a mix of both, all work.

The column data returned are always @VM-delimited, though.

(Btw, and not related to the subject - if you need three levels of data in edit tables (multi-values within multi-values) better use @TM than @SVM.)

- Oystein -

Oysten

Yes the one out of three cases where it worked OK, as I mentioned set_prop took @FM or @VM (I didn't try a mixture). Indeed it returned @vm delimited in any case.

However, in 2 of the 3 identical calls it didn't work with set_prop just feeding in the first element. I recollect the same having happened ages ago and I notified (old) RevTech support.

The difference between the two edit tables involved (one OK and the other not) is simply that they are on different screens, they both have the same names, have two columns, call the same routine. The are in fact invisible so as to feed data to fields automtically and invisibly. Maybe I should check their depths, row limits, etc. in case this might be a possible explanation.

If so, I'll post a confession!

Since last posting I've done some more testing.

Process is :-

Set_Prop data1 into DEFPROP for Edit Table Col1

V1=Get_Prop DEFPROP from Edit Table Col1

Set_Prop data2 into DEFPROP for Edit Table Col2

V2=Get_Prop DEFPROP from Edit Table Col2

Debug

1) I've looked also at properties to see what set_prop is conveying in relation to what get_prop is returning. Answer is that set_prop is the culprit and get_prop seems to be correct.

2) The dodgy edit table was indeed sized for a single row, so I tried enlarging it to various sizes.

a) Hey presto! Enlarging the table depth, I got more than one element returned but not the whole lot.

b) Enlarging bigger than the data being sent and I got a load of trailing @vms

c) Checked no "protected" or row limit which might cause funny business.

d) Tried making this hidden table visible - no effect.

e) Set depth a little shorter than data depth and had a closer look. After set_prop for col1, V1 was short of a couple of elements. After set_prop for col2, data1 had gained an element but V2 was also short of data.

This is odd!

Get_Prop ARRAY, replace col and Set_Prop ARRAY is completely reliable - so I'm not using DEFPROP for an edit table column again until someone says it works!

Richard,

Since last posting I've done some more testing.

Process is :- Set_Prop data1 into DEFPROP for Edit Table Col1 V1=Get_Prop DEFPROP from Edit Table Col1 Set_Prop data2 into DEFPROP for Edit Table Col2 V2=Get_Prop DEFPROP from Edit Table Col2 Debug

1) I've looked also at properties to see what set_prop is conveying in relation to what get_prop is returning. Answer is that set_prop is the culprit and get_prop seems to be correct.

Set_Property DEFPROP Col is guilty of what? Accepting @FM-delimited and even bastardized @FM/@VM data when the docs say @VM? Agree on that.

Or?

2) The dodgy edit table was indeed sized for a single row, so I tried enlarging it to various sizes.

a) Hey presto! Enlarging the table depth, I got more than one element returned but not the whole lot.

I really haven't got any experience with edit tables with explicitly set limits, but I guess you got what you asked for.

Try with Row Limit 0, i.e, no explicit limit. Or -1 if you get a lot of data in your edit table.

b) Enlarging bigger than the data being sent and I got a load of trailing @vms

You'll have to live with that. Strip them off if they're problematic in your further computing.

c) Checked no "protected"…

OK

…or row limit which might cause funny business.

?

d) Tried making this hidden table visible - no effect.

I wouldn't expect it to have any effect. But it might be a good idea to have it visible until you got your form working.

e) Set depth a little shorter than data depth and had a closer look.

You set the number of visible lines less than the Row Limit? Is that it?

After set_prop for col1, V1 was short of a couple of elements. After set_prop for col2, data1 had gained an element but V2 was also short of data.

?

This is odd!

Get_Prop ARRAY, replace col and Set_Prop ARRAY is completely reliable - so I'm not using DEFPROP for an edit table column again until someone says it works!

If your edit table is bound to a data table it makes sense to use DEFPROP!

- Oystein -

View this thread on the forum...