Ok, I'm totally baffled here.. but that's nothing new. Even tho I am a long-time Arev'er, I'm still learning a lot about OI.

Converting a client's Arev system to OI.. working with some old RBasic reports, and trying to port them to Basic+ (Yes, I know I need to rework using Reporter or such, but I'm trying to get it up and running quickly).

The program Selects and Readnexts thru a table, loads @Dict, @Id and @Record, and then uses {} references to access the field data (No, it wasn't my idea). For some reason, occasionally the program seems to be losing the value of @Record. So I save the value of @Record into a local variable and reassign @Record before checking the fields. Now @Record is ok, but when I check the value of the {} reference, it still returns a null. I even went so far as to set "Var=@Record".. @Record has data (according to the debugger), but Var is null.

What am I doing wrong??

Michael

This has been a problem in OI (at least the 16-bit version) for a while. Essentially, the YIELD() option causes loss of @RECORD, @ID and @DICT sometimes. This is particularly true of you call the MSG function with the GasBar option. What I usually do is:

OPEN 'MYFILE' TO MYFILE ELSE .. error

OPEN 'DICT.MYFILE' to FILEDICT then

 @DICT=FILEDICT

END ELSE .. error handling

READNEXT ID THEN

 @ID=ID

 READ RECORD FROM MYFILE,ID THEN

     @RECORD=RECORD

• now if you use gasbar ..

 @ID=ID

 @RECORD=RECORD

 @DICT=FILEDICT

• You can CALL SET_STATUS(0)

• Now do your {} calls

• I'm sure you know that @RECORD is quicker but ..

• be sure your DICT CALLS work!!!

• I have a test form that lets you key in an R/LIST LIST sentence and call R/LIST. It checks STATUS() for errors

Anyway, that's what I've done since converting several AREV apps to OI.

Don

Michael,

Don's way of doing it looks fine to me.

Or you can look at it this way:

I save the value of @Record into a local variable and reassign @Record before checking the fields.

You must save and reassign @Id and @Dict too.

- Oystein -

I've already tried all this, guys.. @Id, @Dict and @Record are all right, according to the debugger, but the {} reference still doesn't work. Neither does @Record… both return a null..

I've worked with Revelation products for over 14 years, and this is just bizarre..:(

Maybe the debugger is wrong too??

Michael,

I even went so far as to set "Var=@Record".. @Record has data (according to the debugger), but Var is null.

We obviously didn't read this last part of your posting properly. Now we are baffled too. (Aren't we, Don?)

Surely you must have made some trivial mistake?? Wrong x??? Instruction not executed for some other reason????

- Oystein -

Oystein ..

Me too. If @RECORD shows up in the System Variables in the Debugger but the "extract" function (Var=@RECORD doesn't provide data) then something is VERY strange indeed. When global variables (@ID, etc.) get trashed, the symptoms are that the READNEXT @ID doesn't take the ELSE path (end of file or error) but the following operations like READ @RECORD FROM FILE_IN,@ID all return NULL data. Obviously, then all dict calls (braces or otherwise) will yield null data too. However, you don't get the VNAV error. The variables are just null.

It might be useful to read the data into non-at variables .. per my previous post .. and to see if the same extract works on these .. eg, Var=RECORD .. note the missing @. If this returns data then ..

@RECORD=RECORD and do the extract again .. NewVar=@RECORD and examine that. Otherwise .. WTFK.

Don M.

C3 Inc.

What happens if you set AtRecord to @RECORD at the beginning of the program? Can you acess the AtRecord variable?

What happens if you change the references to Extract() or just do @RECORD1,10 to pull random characters?

The Sprezzatura Group

World Leaders in all things RevSoft

Ok, I did a Read Record from TableVar, ID; then assign values to @Record, @ID. @Dict is already assigned to the dictionary in question. I test two sets of variables: one using the {} fieldnames, and one using @Record.

In the debugger, ID, @ID, Record and @Record are all set, as is @Dict. However, neither set of variables shows any value.

I know that OI uses @Record, @ID, etc. differently than Arev does, especially within a window/form. But all of my code takes place within a Basic+ routine, so I wouldn't think that there would be a problem. Besides, as I mentioned, all of the necessary system variables seem to be set.

Sorry to be so thick-headed, but I'm out of ideas.

Thanks y'all..

Michael

Try this ..

Go into the Examples application and in the system editor create the following sub. Then from the System Editor Command line enter

RUN Test_Curley

When the debug hits at the bottom you will see that LNameList and FNameList are fully populated.

Subroutine Test_Curley(HeyMoe)

Equ Lname$ to 1

Equ Fname$ to 2

FnameList=" ; LnameList="

Open "DICT","CUSTOMERS" to @Dict Then

Open "","CUSTOMERS" to CustomerHandle Then

  Select CustomerHandle

  Eof=0

  Loop

    Readnext @id else Eof=1

  Until Eof Do

    Read @Record from CustomerHandle, @Id THen

      FNameList := @Fm : {FNAME}

      LNameList:= @Fm : {LNAME}

    End

  Repeat

End	

End

Debug

Return

Now if this is working, and it should be, then *possibly* you are losing @record,@id etc from some other window being called(?).

As you can see here .. this just works

dsig@teleport.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Phone: 503-639-4240

I'm suspicious about your DICT call then because I have no problems with curly braces calls in OI. I remember a case where I converted an AREV 2.12 app to AREV 3.12 and the dict name was converted to underbars but not the internal calls within it. AREV didn't seem to care, and indeed worked with dots inside the symbolic. However, when OI processed it, one of two things happened: No data returned AND the system variables trashed … Openengine error which locked up OI.

I suggest you check your dict calls and, perhaps recompile the dict element(s).

Don M.

View this thread on the forum...