Change commands missing from Retrieve

Hi Bob,
Hmm, have to have a look.
George

Robert: And if I did, how would I even spot it?

The only places the Retrieve Object is referenced are where the command processor passes the command and says "Store this" and the RETRIEVE and CRETRIEV commands which ask for retrieval. I mean it really can't get much simpler. I'm not doubting there is something odd happening, people don't report stuff for no reason, but without some reasonable clues I'm left with staring at code which works 99% of the time. I test, and it works, reading code does not solve this.

George

I've done the RESET RETRIEVE and am trying to duplicate the problem (and find a pattern), but of course now it's not occurring. I'll keep trying.

Is it possible that clearing the stack fixes the problem, at least temporarily?

Bob

When SPFLite starts, the previous retrieve stack is loaded. It doesn't matter how many are in the CFG file, it doesn't validate the control entry since it will handle a real number < or > 50. It either throws away those over 50 or inserts nulls if under 50.

There is no top-of-stack or current-stack pointer saved in the CFG file, the retrieve pointer is always started at the 1st entry.

RESET RETRIEVE simply nulls all 50 entries and resets the pointer to the top.

Stefan: RESET RETRIEVE doesn't work in FM because the Command Table is simple minded and has RESET flagged as Edit only. The command vakidation table doesn't get down into operand level fine-tuning.


There's really no such thing as the stack being "wrong" and staying wrong. It's a simple 50 item array, with one single pointer to the 'current' entry. Forward and backward retrieve simply INCR or DECR the pointer, handle wrap-arounds, and return the entry. New entries are always inserted at the top, and all others pushed down, with the 50th entry dropped from the end.

The Retrieve object code is trivial, hardly worth putting into an Object structure. But if anyone can spot some stupidity in here, that would be great.


_ObjRtr.inc (6.77 KB)

George

I think I found something...

I have F5 set to RFIND, F6 set to RCHANGE, F12 set to RETRIEVE, and CTRL set to ENTER.

If I key in a CHANGE command and press CTRL, then F12 retrieves the CHANGE command.

But if I key in a CHANGE and press F5 instead of CTRL (to see where the CHANGE will occur), and maybe follow with F6 (to perform the CHANGE), then F12 doesn't retrieve the CHANGE command. It looks like it doesn't go into the stack.

Same thing happens if I key in a FIND then press F5 instead of CTRL, the FIND isn't in the stack.

-----------------------------------------------

Could it be that keyed in FIND and CHANGE commands don't go into the stack if they're triggered via RFIND/RCHANGE instead of ENTER?

So maybe it's not a problem with the stack, but an issue with RFIND and RCHANGE.

Hope this helps,
Bob

bobd: OK, tracked it down. It has to do with how commands entered manually, and commands entered via a PFK key (with other commands present on the command line) are handled as far as Retrieve is concerned. (Yes, it gets very convoluted)

I think I've added yet another wrinkle to the logic to handle it. There's a new Beta, I'd appreciate some feedback.

George