We have an app that is producing multiple invoice records based on batch processing. We have a batch record which contains info about the date and selection criteria used to create the batch. Including a multivalued field called clients.

First problem:

The field was defined as single valued. No matter how hard we tried to update the bound control the write would strip all but the first value from the actual record. Changing the dictionary to Multivalued seems to cure this problem. Can anyone confirm this kind of data manipulation by the write process?

Second problem:

After chaning the field to Multivalues the code needed to pass the entire Batch Record to a subroutine.

We used…

x=Set_property(WindowName:".CLIENTS","TEXT",clients)

Batch_Rec=Get_Property(Windowname,"RECORD")

…

This returned one more than the number of values in clients.

Example: if clients had "120":@vm:"121" then Batch_Rec would be "120":@vm:"121":@vm:"121".

In addition each time we ran the process and removed the extra values it kept increasing the number in batch rec by one!!!

I am able to work around this by forcing the value in Batch_rec to be correct but it brings up a potential bug in how the RECORD property is updated.

Thanks,

John Bouley

John-

Issue 1 is designed operation, in the product since OI 2.0

Looking at issue 2.

Thanks!

1) it is a design feature

2) this shoulds like the old getprop of a table giving the number of values that there are rows in the control.

Does the Record property always have 1 more

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 971-570-2005

OS: Win2k sp2 (5.00.2195)

OI: 4.1.2

Design feature… guess I missed that one…

Yes it always has one more than when the record was read.

John

John,

Regarding Issue #2, this is an old bug that we reported here more than a couple of years ago. To my recollection this was never acknowledged…but then that was the old Revelation at the time. I hope the new Revelation will fix it even though we've worked around it for all these years.

[email protected]

SRP Computer Solutions, Inc.

Don - I had a look at that old posting. Did you really put values containing @FM in a databound field? Isn't that asking for trouble?

John - in that old posting of Don's he says other delimiters than @VM (or @FM) don't cause any problem. Is it possible for you to switch to a different delimiter for the CLIENTS field, say @SVM? (I think I might have had a case similar to yours. I had some fields with multivalues and sub-values which I kept in a hidden edit table. I started out with @VM and @SVM as delimiters, but had to switch the sub-delimiter to @TM (or @STM - I don't remember exactly) since the edit table went and truncated cell data at @SVM.)

- Oystein -

Oystein,

I had a look at that old posting. Did you really put values containing @FM in a databound field? Isn't that asking for trouble?

You should have read your immediate response to that posting. You said:

I can easily reproduce the problem. But I don't understand why you expect it to work with @FM. And I don't see why you would use @FM in a databound control at all.

To which I replied:

BTW, you are correct in that @FM would not be a normal delimiter to use. I discovered this because our code was using the Insert function but using the field mark position by accident. I then went and tested for all common delimiters and discovered that only @FM's and @VM's cause the problem.

Maybe the UFO that you saw here caused you to overlook this stuff.

[email protected]

SRP Computer Solutions, Inc.

Let me know if you find anything.

Thanks,

John

View this thread on the Works forum...