I recently upgrade to OI 9.0 from 8.x and am noticing some peculiar behavior with the BTREE.EXTRACT function versus Arev31 and (I believe) OI pre-9.0. It seems that the OPTION parameter is reset to 0 with the function call.

OPTION=1

CALL MSG(OPTION)

CALL BTREE.EXTRACT(SEARCH.STRING,SEARCH.FILE,DICT.FILE,HITS,OPTION,FLAG)

CALL MSG(OPTION)

produces first a message box saying, "1". After the call, the OPTION is said to be "0". Is there any reason why this value would be reset with this function call? I checked the parameters between my Arev31 build and they seem to be the same as this one in Arev32.

Thanks.

Mat, in your example it is the MSG call that is clearing out the option literal.

Bob,

Am I understanding this right that a call to MSG function has the side-effect of clearing the value of a variable? If so, what is a better way to get feedback on a variable's value in Arev32?

On a side-note, does a debugger similar to OI's exist for Arev32? Using the built-in arev debugger is like pulling teeth, i.e. I am unsure how to use it effectively.

Thanks!

Why don't you change your examination to

X=OPTION

call msg( 'Returned ': quote( X) )

thus, you don't change the value of X

Dave

btw use ? in the debug to see parameters

Dave, your suggestion led me to the solution of first preserving the OPTION value the restoring it after the call to BTREE.EXTRACT:

X=OPTION

BTREE.EXTRACT(…,OPTION,…)

OPTION=X

However, this still leaves me wondering why the OPTION variable's value is locally corrupted by the call to BTREE.EXTRACT. This doesn't seem to be the case in previous versions of Arev. Am I mis-understanding the intention of the parameters?

Thank again!

Or you could just Call Msg( Option:'') - which would effectively pass the Option variable 'by value' instead of 'by reference'. Use Option+0 if you want to pass it as a number.

Cheers, M@

[img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img]

View this thread on the Works forum...