{{tag>category:"OpenInsight" author:"Donald Bakke" author:"Oystein Reigem" author:"[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]"}}
[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]
==== Bug Report - DEFPROP causes RECORD property to expand (OpenInsight) ====
=== At 10 MAY 2000 06:10:04PM Donald Bakke wrote: ===
This was a very weird bug to figure out. We have already called it in to tech support but since that time we have made several more discoveries and thought we should share them here for everyone's review.
We have a hidden databound editline on a form that we use to hold a multi-value list of data. Programmatically we manage the DEFPROP property this editline. Today a client reported an "ENG0703 Set_Property, line 1, variable exceeded maximum length" error. When we looked into the problem we discovered that the length of the string we were attempting to update was only 28K in length (then length of the control name was only 15 characters, so we were well within the overall limit of 64K.)
Upon further investigation we discovered that this problem would only occur on the third attempt that the program would update this editline while in the same record. Our debugging showed that while the DEFPROP property of the control was always correct, the RECORD property of the window would keep the original data and then append more to itself. Therefore, by the third iteration the RECORD property would exceed 64K and cause a VEML error. It should also be noted, however, that if we write the record before it gets a chance to "blow up", the actual data being written is correct. Therefore, the WRITE event correctly reassembles the individual control properties even though the RECORD property doesn't visually comply.
This causes us two problems that are affecting the ability of our applications to perform:
1. The occasional crash of the system when the VEML occurs, and
2. The unreliability of the RECORD property. We depend on this property for printing forms and updating the database. If the information in this property is not accurate then this will have a serious impact on our systems (as well as many others I would imagine.)
Here are the conditions that cause this problem to occur:
1. Must be an editline or editbox. Edittables are immune.
2. Must be databound, otherwise the RECORD property won't get updated.
3. Must have at least one @FM or @VM character in the variable. Other delimiters or no delimiters don't seem to cause this problem.
4. Must use the DEFPROP or INVALUE property, otherwise the RECORD property won't get updated.
5. The number of times the code can be launched before failing is equal to 64K divided by the length of the variable.
This is an easy bug to test once you know what you are looking for. Just add some code to a CLICK event like this:
Var=A":@FM:Str("B", 100)
For Loop=1 to 1000
Set_Property(@Window:".EDITLINE_1", "DEFPROP", Var)
Record=Get_Property(@Window, "RECORD")
call Send_Info(" ":Len(Record))
Next Loop
The Len(Record) will continue to grow (until 64K) and the Loop variable will get to around 640 before it crashes.
Thank you for your attention to this.
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 11 MAY 2000 05:02AM Oystein Reigem wrote: ===
Don,
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.
But regarding @VM I agree it's a bug. If it's got something to do with putting mv data in controls meant for single value data, OpenInsight should at least offer an alternative. By rights an edit table should be the proper control to use.
Another comment: You say "append". But it's more of an insert. Assume RECORD after the first iteration is "A":@VM:"BBB" (I've reduced the number of B's from 100 to 3). Then - if everything worked correctly - in the next iteration the whole "A":@VM:"BBB" should have been replaced by a new "A":@VM:"BBB". But what happens is that just the "A" has been replaced, making RECORD become "A":@VM:"BBB":@VM:"BBB".
- Oystein -
Øystein Reigem,
Humanities Information Technologies,
Allégt 27,
N-5007 Bergen,
Norway.
Tel: +47 55 58 32 42.
Fax: +47 55 58 94 70.
oystein.reigem@hit.uib.no
Home tel/fax: +47 56 14 06 11.
[img]http://www.hit.uib.no/oystein/g-anim.gif[/img]
----
=== At 11 MAY 2000 09:08AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote: ===
[notag]So presumably the bug must be that the code which updates DEFPROP must say
@Record = NewValueString
instead of
@Record = NewValueString?
Roll on CSP so we can fix this sort of thing ourselves .
[The Sprezzatura Group]
[World Leaders in all things RevSoft]
[
]
[]
[][/notag]
----
=== At 11 MAY 2000 11:42AM Donald Bakke wrote: ===
Oystein,
Your description is a little more accurate than mine. When I wrote the initial post I was concerned that there was so much detail that it would get too confusing to understand. Thanks to you, and Sprezz, for looking it over and confirming the bug.
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.
We are using an editline (rather than an edittable) because the edittable's cell only stores up to 999 characters. This approach is an adaptation of Cameron's knowledge base article on how to bind large amounts of data to the edittable. The trick is to store the data in an editline and programmatically manage everything.
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 11 MAY 2000 11:56AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote: ===
[notag]We wondered why we hadn't run across this problem before and then realised that with editlines we use for storing MVs we never use DEFPROP we use TEXT as there is less need to trigger lostfocus events! Close escape for us as we use this extensively at Penguin Books.
[The Sprezzatura Group]
[World Leaders in all things RevSoft]
[]
[]
[][/notag]
----
=== At 11 MAY 2000 12:23PM Donald Bakke wrote: ===
Sprezz,
Then do you just set SAVEWARN yourself? Do you ever need the RECORD property for anything like printing a form?
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 11 MAY 2000 12:34PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote: ===
[notag]We use it at Penguin purely as a place holder. A production run for a title may use several items, each of which may be split between various accout codes in various proportions. So we have associated edit tables and these are kept in sync via the hidden editlines. We handle SAVEWARN ourselves OR ignore it.
As for RECORD - as we've never trusted it we tend not to use it.
[The Sprezzatura Group]
[World Leaders in all things RevSoft]
[]
[]
[]
[/notag]
----
=== At 11 MAY 2000 05:43PM Oystein Reigem wrote: ===
Don,
I haven't read Cameron's article, but I figured I knew why you didn't use an edit table.
The only, and rather inferior workaround I've been able to come up with is to erase the field in RECORD before setting DEFPROP:
Record=Get_Property( @Window, "RECORD" )
Record="
UnUsed=Set_Property( @Window, "RECORD", Record )
UnUsed=Set_Property( @Window : "...", "DEFPROP", Value )
Not very attractive.
- Oystein -
----
=== At 11 MAY 2000 08:16PM Donald Bakke wrote: ===
Oystein,
I was going to test that approach when I got the chance. I wasn't sure if the RECORD property was "set"-able that way. You are right, this is not a great workaround as we would theoretically have to update all code every to account for this. Fortunately there are really only a few places where this would normally blow up like this.
Thanks,
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=4660E65BB871F33B852568DB0079C592|View this thread on the Works forum...]]