Emu48 Edit a CSV File
|
01-09-2022, 02:34 PM
Post: #18
|
|||
|
|||
RE: Emu48 Edit a CSV File
(01-08-2022 07:41 PM)MNH Wrote: I'm still not understanding your syntax. I understand targ means target or the part of the string, what I call FILE, with the 10 CHR (line feed character). Also, len means length, or the SIZE of FILE. What is new? Is it the replacement for targ? REPLS is a generic string replacement function, and isn't specific to just this application. It takes three arguments on the stack: SL3: Source string SL2: Target string to be replaced SL1: Replacement text that takes the place of target All instances of the target string in the source string are replaced by the replacement text through one invocation of the function. The result is left on the stack at the completion of the function. The locals used by the function are: targ: the text which will end up being replaced in the source string new: the replacement text for each target encountered len: the length of the target text (not the length of the source text) Note that the source string is not a local, but is instead broken into two parts left on the stack during processing: a "result" string, and the "remaining characters" string. Consider these examples, which are unrelated to your application but are included here to show how the function works: "ABCDE" "BCD" "X" REPLS => "AXE" "123 456 789" " " "" REPLS => "123456789" "1,222.333,0,99999999,88,123.456" "," 10 CHR REPLS => "1 222.333 0 99999999 88 123.456" (01-08-2022 07:41 PM)MNH Wrote: I can't figure out how to use C$ n. I get 'C$ n' on the stack when I use it. "n" here should either be a number, or "$". If a number, it defines the number of characters that follow which are considered to be the contents of the string being defined (ignoring the separator space that follows the number). "C$ $" simply means that the rest of the current line (up to the next linefeed) is all considered to be the string being defined. The "C$ <number>" does NOT show up in the program after you are done editing. Instead, the actual string that you defined is in its place. The C$ construct is an editing aid, and doesn't actually get saved into stored code. "C$ <whatever>" is used in this situation to make it easier to create a string object that contains double quotes while editing the program. Here's the description of C$ from the Advanced Users Guide for the 49-50g (I didn't see it in the AUG for the 48G): Quote:Enters C$ on the command line to help with the manual entry of a string object. Must be followed by a number indicating the number of characters to include in the strings, or an additional $ to indicate that the rest of the command line is a single string. There must be exactly one separator character after the second $ and before the body of the string. If the declared length is greater than the number of characters actually available, the string is automatically truncated to the correct length. C$ works on both my 48G and 48GX calculators, as well as EMU48 with a 48GX ROM and skin set. In my situation, all are using Rev. R ROMs -- check your version with the VERSION command to see which version you are running. (01-08-2022 07:41 PM)MNH Wrote: I wrote STORE to remove the line feed (LF) characters from the FILE string. It made sense to... This is essentially the same thing that my suggested code is doing. Rather than embedding all of the code in an application-specific code block, though, it separates the string replacement function into an independent function which can also be used in other contexts/applications. (01-08-2022 07:41 PM)MNH Wrote: Please note that all substrings will not be of equal lengths, because some coordinate pairs will have point numbers containing 1 to 5 digits. This isn't an issue with the code I suggested. It doesn't care about length of the embedded strings. (01-08-2022 07:41 PM)MNH Wrote: Also, an actual coordinate file will be in the form of P,N,E,Z,D (e.g., 208,1531217.411,520676.455,98.393,IRC 1/2 LB 6300) where: The quantity of numbers defined isn't a problem for my suggested code, but the format of the description could be. STR→ takes whatever is given to it and tries to interpret it as if you typed it into a command line and pressed the ENTER key. If you type numbers separated by commas into the command line and press ENTER, you will end up with those same numbers being placed on the stack in sequence (which would also be the same as what you would get if the numbers were separated by spaces instead of commas). Everything is fine up to that point. In your example given above, that final description has no enclosing double quotes. So that sequence of characters would be interpreted by STR→ as standard RPL code, which would likely result in an error due to what it contains. Using the method I suggested would only work with the above example if you already had enclosing double quotes surrounding the text of the description. That would require a different approach in this situation, so the method I described would have to be augmented to handle that kind of input. At that point it would probably be simpler just to use application-specific code that would handle the description appropriately. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)