Discussion:
Intermittent seeker trouble: invalid subscript ref
(too old to reply)
David Stone
2008-11-03 17:25:00 UTC
Permalink
A seeker on a form has been working normally for years, but after
updating to a new version of a gov't database (same fields, same
indexes), I now get, when entering a "w" (no other letter before or
after "w" in the alphabet!) an "invalid subscript ref" error with a ref
to line 110 of the seeker control, which is this one:

lRet = this.seekRowset.findKeyNearest( this.normalizedValue() )

in the oSeek function below.

FUNCTION oSeek
local lRet
lRet = this.seekRowset.findKeyNearest( this.normalizedValue() )
if ( this.seekRowset.endOfSet )
this.seekRowset.next( -1 )
endif
RETURN lRet

If I click the Cancel button on the error box and then type a new first
letter other than "w" in the seeker (either before or after "w" in the
alphabet), the seeker works as expected, and after that successful seek,
starting a new seek with "w" then works as expected also. [sigh]

The field is a 200-char description indexed as

upper(left(DESCR,100))

and I have reindexed the table with no effect on the error, and also
reindexed as upper(left(DESCR,90)) with no effect.

The problem table is the form's rowset, and specifying the seeker's
rowset in the form's init has no effect. The index is set in the form's
dmd and is redundantly re-set in the init and the rowset topped at first().

Navigating in the rowset before using the seeker has no effect, and
doing a successful seek for another letter before seeking "w" has no
effect--as described above, a "w" seek is only successful if the error
has been generated and canceled.

Any idea which "subscript reference" is being referred to in the error
msg, or what might be going on to cause the error? I have never seen
this before despite using many seekers in many apps.

David
David Stone
2008-11-03 17:31:12 UTC
Permalink
Post by David Stone
If I click the Cancel button on the error box and then type a new first
letter other than "w" in the seeker (either before or after "w" in the
alphabet),
Mistake: even typing a "w" at this point works as expected (no error).

David
Bruce Beacham
2008-11-03 22:00:53 UTC
Permalink
Post by David Stone
Any idea which "subscript reference" is being referred to in the error
msg, or what might be going on to cause the error? I have never seen
this before despite using many seekers in many apps.
I'd suspect a codeblock - that's the usual reason one gets a line
pointer to a line of code that looks quite harmless. Have you a
canGetRow on this rowset, or a beforegetvalue on this or any other field?


Bruce
David Stone
2008-11-05 04:25:50 UTC
Permalink
Post by Bruce Beacham
I'd suspect a codeblock - that's the usual reason one gets a line
pointer to a line of code that looks quite harmless. Have you a
canGetRow on this rowset, or a beforegetvalue on this or any other field?
Hi Bruce, there is only an onNavigate for the rowset that checks a
variable and conditionally calls a form method, but it doesn't do
anything that should differentially affect a seek for "w". Taking it out
makes no difference.

As a workaround, I enclosed the seek in a try/catch:

FUNCTION oSeek
local lRet

do while true
try
lRet = this.seekRowset.findKeyNearest( this.normalizedValue() )
exit
catch (exception e)
loop
endtry
enddo

if ( this.seekRowset.endOfSet )
this.seekRowset.next( -1 )
endif
RETURN lRet

and it makes the problem go away.

David
David Stone
2008-11-05 04:51:47 UTC
Permalink
Ah--found the problem. The app was pointed to a different copy of the
seeker.cc than the one in the current folder, and in that one I had made
this small (so I thought) change for reasons that I now do not recall:

FUNCTION normalizedValue
* RETURN this.value.rightTrim().toUpperCase()
RETURN rtrim(upper(this.value))

Problem is fixed when the original code is used. No idea why it objects
to seeking a "w", but it's nice to have things back to normal.

David
David Stone
2008-11-10 17:29:55 UTC
Permalink
Post by Bruce Beacham
I'd suspect a codeblock - that's the usual reason one gets a line
pointer to a line of code that looks quite harmless.
Hi Bruce, I have now had a couple of additional errors to do with
rowsets in other forms, and your tip above has revealed the causes:
pesky codeblocks. Thanks.

David

Loading...