Here is my first SPFLite macro. I quote from the macro header:
' CsrFind.MACRO ' ' Issue a FIND command with the find target defined as: ' If there is a text string selected, it becomes the find ' target, ' If nothing is selected, the word starting with the cursor ' position is the find target. A word ends with the next ' character that is not a letter, a number, '-', or '_'.
Nice job. One suggestion, as this is something that is only too easy to have overlooked, rather than hard coding the letters making up a word, you can ask for the list associated with the current Profile using the Get_Profile$ function.
e.g. your line:
Dim WordChars As String Value "abcdefghijklmnopqrstuvwxyzåäöABCDEFGHIJKLMNOPQRSTUVWXYZÅÄÖ0123456789-_"
could be done as:
Dim WordChars As String Value Get_Profile$("WORD")
George, Thanks for your nice words and the tip. I implemented it right away. As I wanted to include a few special characters from my native tongue and - and _ that are frequent in variable names I changed it to read: Get_Profile$("WORD") & "åäöÅÄÖ-_". A citizen of another country would probably want another set of extra characters.
By the way, now I came to think of another feature that would be nice to implement in the macro: Would it be possible to have the FIND command end up in the list of commands that can be retrieved by the RETRIEVE command. Sometimes the string that you put the cursor on is not exactly the one you want to search for. You might want to change a few characters and do a new search or just do the same search a minute later when you don't have the original string in front of you on the screen. I don´t mean that I want the FIND command to end up in the retrieve list as an alternative to issuing the FIND, only that it would be nice if it could be retrieved after the FIND has been issued.
I have written a macro with the same logic in my 3270 emulator. There the FIND command gets placed in the retrieve list, but that is natural because the emulator is external to the ISPF editor and really puts the FIND command in the editor command line and presses Enter.
Len: You should also look at the option to include international characters under Options -> General -> Include international characters for WORD/Alphabetic Pictures? It may of course add too many since it includes basically all the ASCII European characters.
As to adding a command to the RETRIEVE stack. I'd be very leery of that. For your macro, it would not be a problem. But think of a macro that is looping through the whole file by doing successive FIND commands. The stack would be full of FIND commands.
George, I keep being amazed by all the features you have included in SPFLite. I will change my macro once more and remove my national characters. I changed to "Include international characters" and performed the "erase Normal characters for P'.' picture literals" trick, as I had earlier modified that string to include my national characters".
The fact that there are a lot of irrelevant international characters in the string does not matter since those characters are not present in the strings that I am interested in handling. Marvelous!
Another wild idea for the retrieve issue, if you would be interested: What about making the inclusion of SPF_Cmd commands in the retrieve stack optional by prefixing the command string with &. In my mind that would make some sense, since & normally means "retain the command on the command line". The meaning in macros would then be "retain the command in the retrieve stack". The command would be saved in the retrieve stack without the &. Then it is of course another matter if this is at all doable and if there are drawbacks that I don´t see.
The & code on the command line means that the command is "retained" on the command line, but is not put on the stack. For SPF_Cmd, there is no need to "retain" a command, since it's just a string expression, and if you needed it again, you'd just re-issue the same string expression.
This issue is similar to the ! on the command line to clear any prior contents, which is useful in some key-mapped commands. You wouldn't need an ! in a macro, because there's no command-line to clear; it's just the SPF_Cmd expression with is re-specified each time.
If you wanted to use some code to mean, "be sure to put this command on the stack" then maybe you want a code for key-mapped commands that says, "don't put this command on the stack". One of the commands I (sometimes) wish were not on the stack is END.
Suppose you had a code of ~ and had it mean, "whatever you were going to do regarding the stacking of the current command, do the opposite".
That would handle both situations, and would avoid creating a 'contradictory' meaning for the & code.
It's possible that a key-mapped command might need both ! and ~ so the parsing for this would have to be done carefully.
If you don't like END, maybe you should set the minimum command length for Retrieve to 4 or higher. The purpose of the setting is exactly that, don't retain commands that are just as quick and easy to re-type. If you did so, commands of length 3 and under would not be retrievable, not exactly a big loss.
It isn't a matter of the command being easy to type or not. It's that I don't want to retrieve it at all. The fact is, I never type an END command. I always use F3. But if I am retrieving commands and there was an F3 used, END gets put into the stack. However, I might have a CHANGE command as C, and just because it's short doesn't mean it's not important. I don't think that equating 'importance' with 'command length' is a valid assumption - at least not always.
In any case, if you were going to recognize some kind of code in SPF_Cmd to force an entry onto the stack, it seems reasonable to have a code to avoid the stack. Just saying ...