Hi, I am working on a radio controller for the Icom PCR-1000 for now, so I can't go very deep into this, but I have some ideas that might help.
The main problem is the user modification. It rules out arrays because they waste a LOT of space when string lengths are very different, and they can't be stored easily for transfer to another machine or pack.
Data files can have large record counts and with just one field per record it's easy to save space, reference the string, and change the file. There are two vital points: ALWAYS use a RAM pack for each file (one per list), and you can only have up to four lists open. You may only need one at a time.
Prepare data files to go with the program, don't have the program create them because there would be a lot of duplicate data if you do that. A Windows text editor is ideal to make these files because you just put one string per line, and the CRLF line ending used when saving the file is the same thing the Organiser wants as record separator. Just make sure that the last line is also terminated, i.e CRLF at end of file. Rename as File.ODB then import it to the Organiser with anything that handles Organiser files.
Searching a large file is slow unless you keep track of where to start a search based on prior knowledge of something that lets you limit the scope, but I assume you only need to iterate through the list with the NEXT and BACK commands or use POSITION POS+N if you want to step through a large list in large steps.
Adding user entries will always put them at the end, so LAST then repeating BACK will scan for those if you know you need a recent entry to the list. Inserting new items at a current position in a list is VERY slow if the insertion is at the start of a long file, and the code to do it is larger than is justified except in logs that have records whose position must be preserved, like timestamps or ordered lists of radio frequencies. etc.. If you want alphanumeric sorting, it's best to do it as periodic maintenance, and several OPL programs can be found for sorting files.
Files are by far the best way to do this because the Organiser is dedicated to file handling as one of its most important abilities. There's a lot of support built in, and plenty added by others. You may find something that can act like a code library to solve a bulk problem like this.
Using VIEW() for records and EDIT for your user string lets you choose a new string, or return to what's still in the string if you press ON/Clear. EXE to select the string from the file by direct assignment of the string.
Once a file is OPEN, and USE has selected the right file if more than one is opened at once, this OPL procedure can navigate the records using the keys A~F without overshooting either end of the list:
Code: Select all
REM One file open as A, one field per record as S$.
WHILE KEY :ENDWH
IF EOF :CLS :PRINT"No Records Exist" :K%=GET
IF K%=1 :RETURN 0
ELSEIF K%=65 :P%=1
ELSEIF K%=66 :P%=COUNT
ELSEIF K%=67 :P%=P%-10
ELSEIF K%=68 :P%=P%+10
ELSEIF K%=69 :P%=P%-1
ELSEIF K%=70 :P%=P%+1
ELSEIF K%=13 :RETURN P%
IF P%<1 :P%=1 :ENDIF
IF P%>COUNT :P%=COUNT :ENDIF
If the ON key is pressed, 0 is returned, indicating that no selection was used.
If the EXE key is pressed, a nonzero return points to the selected record, and you can copy it to a string for editing. If the committed entry compares equal to the record, the string is accepted. If it is not, it is also accepted but you can prompt first to ask if the edited version is to be added to the list with APPEND. Deleting a record is also possible but I left out code for that to keep the template clear and easy to read.
A useful editor is this:
Code: Select all
TRAP EDIT E$ IF ERR=206 :RETURN :ENDIF
That lets you use ON twice, the first clears the string for new input, the second exits the editor and leaves the original string intact if you decide not to edit it.