|
|
Post by George on Jul 20, 2018 11:11:52 GMT -5
I know how you feel when I say I can't really look for your errors, but try and appreciate my side, it truly is fruitless reviewing code that works when I try it, and works normally 99.9% of the time elsewhere.
George
|
|
|
|
Post by Jo on Jul 24, 2018 16:08:55 GMT -5
Robert,
thank you for posting this description, I did not realize, that this "last command" was already stored, I thought the command was lost. Now that I know, RETF (also shift F12 in my case) will bring that "lost" command back makes me happy.
Of course, I'm looking for a reproduceable szenario. But you should know, I've seen this sometimes, often when I RETRIEVE a command and modify somesthing, and then RETRIEVE again .... (I think. I have to try .....)
Jo
|
|
|
|
Post by Jo on Jul 25, 2018 9:38:31 GMT -5
Hi Robert, George!
Go to FM and enter "FF A" command. Nearly all files are found, you decide to be more precise:
use F12 (RETRIEVE) and modify the FF A to be FF AB, press enter. Select one of the files.
Press F12 and expect FF AB, but FF A shows up.
Jo
|
|
|
|
Post by George on Jul 25, 2018 10:37:16 GMT -5
Jo: Shows how frustrating this all is. I did exactly as you said and it all worked fine. Tried it a couple of times.
George
|
|
|
|
Post by nicc on Jul 30, 2018 4:51:04 GMT -5
I have been following this discussion. I tried Jo's scenario and I got the same result. But, I was not on the lates version so I did not contribute. Now I have upgraded, repeated Jo's scenario and no problem found. Just to be sure, I repeated the test - still no anomaly.
|
|
|
|
Post by George on Jun 29, 2021 10:37:58 GMT -5
All: I have completely re-written the RETRIEVE/RETF stack handling. Not that I pinned down the actual cause of the intermittent failures, but we have to try something, and tidying this up has simplified it considerably. Note that RETF is slightly different, it will only reverse if you have already used RETRIEVE to move down ths atack. i.e. if you hit RETF as the 1st retrieve cmd, it will say "No (more) RETRIEVE entries". I don't see this as a problem as it is really designed to handle the "Oops, I hit RETRIEVE too many times" situation. I'd appreciate some feedback in checking this out. George SPFLite25.exe (543 KB) |
|
|
|
Post by George on Jun 29, 2021 12:31:57 GMT -5
The re-write has ONE external RESET, at the point where a command (whether typed or retrieved) has completed processing.
And who says the stack must be circular?
If you don't reset, then if you want to RETRIEVE, execute it, RETRIEVE, execute it repeatedly, it won't work because without the RESET, you will get the 2nd, then the 3rd etc. command from the stack.
As to doing RETF at the top of the stack - you really want the 50th oldest command?
Did you actually try this version?
George
PS Most of your objections are no longer even in the code, and the stuff is packed away nicely in an Object, just as you recommended.
|
|
|
|
Post by George on Jun 29, 2021 12:50:55 GMT -5
Further to the circular argument. If you have a circular stack, and maintain an insertion point for new items, and a current item pointer, it acts exactly like the push-down stack with wrapping from bottom to top. There is no advantage. If you want RETF to wrap to #50 if the pointer is at the top, that's a no brainer. I just thought it was totally un-needed. George OK, here's one with RETF altered to wrap the same as RETRIEVE wraps. Please give it a try. George File removed, to be replaced when I get it working a bit better. Attachments:SPFLite25.exe (543 KB)
|
|
