Clairon 12 13999 - ABFILE.CLW: increased buffer sizes for Pos, Hold, and Current:Position to STRING(2048) to hold POSITION()

1

This discussion of POSITION() string size in code can be split to a separate topic since it also applies to all prior versions. This was STRNG(512) in C5.

The intent of my original post was to note that 13999 had just this minor change to LibSrc and none to Templates. Original Post:

Each release I compare LibSrc and Templates to find changes.

In 14000 there are changes in LibSrc to only ABFile.clw in 3 lines with a Position variable defined as STRING(1024) changed to STRING(2028).

SaveQueue                     QUEUE,TYPE,PRIVATE
Pos                             STRING(2048)

Hold  STRING(2048),AUTO

Current:Position STRING(2048)

This was in the changes file. I confirmed nothing else changed.

The intent of my post was to note that LibSrc had only only this minor change to ABFile.clw, and none in Templates.

2

Personal opinion, but the 2048 size still leaves the POSITION to cause potential Error 78’s

The problem is, e.g. SaveQueue.POS = POSITION(KEY) needs to be able to hold the accumulated size of the Key being used, if that exceeds 2048 characters, which in certain circumstances it can, the Error 78 still rears it’s ugly head.

Mark

3

I’ve had to increase the size of the filter string in the past.

4

I had a PTSS to get it made bigger Mark, but alas it only got bumped to 2k, which i agree is insufficient. It will help though to tell SV about this as the impression seems to be that no one is complaining about it.

5

As did I Bruce :slight_smile: PTSS Report, requires login

6

How about a nice 2049, then?

7

STRING(∞) then it can be bigger than the known universe!!! :thinking: :wink:

8

Why not convert Pos to a dynamic string object like IDynStr?

9

There are several approaches here. But bear in mind this is in the ABC classes, so typically SV tries to minimize changes there.

Yes, rearchitecting the class to use a dynamic-string-object would be the best solution. But it would also be the most complex, and would have the biggest risk of side effects.

Making the size value an equate would allow developers to extend it more easily if necessary.

Bumping it up to say 16k though would be low risk, while basically solving the problem. (Technically its possible to need more than 16k but i suspect that would be a contrived situation.)

10

Changing only ABFile.CLW seems incomplete.

If you look in LibSrc you’ll find several other POSITION() variables of STRING(1024) that did not get changed.

File|Line|Procedure|Code
abbrowse.clw|869|BrowseClass.ResetQueue|HighlightedPosition STRING(1024)
abbrowse.clw|1595|BrowseClass.UpdateViewRecord|Pos STRING(1024),AUTO
abvcrfrm.clw|421|FormVCRClass.CheckBorders|LastRecordPosition STRING(1024)
abvcrfrm.clw|497|FormVCRClass.Fetch|LastRecordPosition STRING(1024)
abvcrfrm.inc|16||ViewPosition STRING(1024) !Entry's view position
abwindow.inc|84||LastInsertedPosition STRING(1024),PROTECTED

Templates that generate a Position String. There are more.

File|Line|Template|Code
abbrowse.tpw|2095|#GROUP %ConstructQueue|#GROUP(%ConstructQueue, %pDescription='', %pAddMark = %True, %pPositionSize = 1024)
abreltre.tpw|321|RelationTree  #CONTROL|%[20]ValueConstruct STRING(1024) #<! Record POSITION in VIEW
abreltre.tpw|328|RelationTree  #CONTROL|%[20]ValueConstruct STRING(1024) #<! Record POSITION in VIEW
abreltre.tpw|337|RelationTree  #CONTROL|%[20]ValueConstruct STRING(1024) #<! POSITION of a new record
ctlbrow.tpw|862|BrowseBox  #CONTROL|%[22]ValueConstruct STRING(1024) #<! Queue POSITION information
ctlbrow.tpw|957|BrowseBox  #CONTROL|%[20]ValueConstruct STRING(1024) #<! POSITION of located record

#GROUP %ConstructQueue generates the Browse:Queue field ViewPosition STRING(1024) !Entry's view position