Post by Robert on Jun 20, 2023 8:28:18 GMT -5
When editing a file that contains an IMACRO defined in its profile, it might be desirable for the IMACRO to be able to determine if the file in question is being opened using EFT extensions, since those extensions might change the nature of the file, and might require slightly different IMACRO handling.
What is needed for that to happen is some means of conveying a "message" that the file is being opened in a different way. The question is, how to convey that message.
A few possibilities come to mind.
1. If the SUBARG profile setting were allowed as one of the new EFT operands, it could be used to pass a token, which could be fetched with Get_Profile$("SUBARG").
2. If a SET command were allowed as one of the new EFT operands, we could say SET name = value, and then fetch it with GET_SETVAR$().
While these ways would work, they have one disadvantage, which is that they set values permanently. Once a SET name is set, it is set globally. I am not sure how SUBARG would work under the current EFT extensions proposal. Would it be permanent or temporary? If it were temporary, then SUBARG might be the easiest solution and take the least amount of work.
Should (1) or (2) not be enough, it is possible some new means could be devised.
3. Suppose the EFT line allowed a new operand of:
EFTARG string
Then, there would have to be a new macro function like Get_EFTARG$(), or possibly GET_Profile$("EFTARG").
The main point is that the EFT argument would be local to that usage of the the given profile and EFT line. Its setting would be temporary rather than permanent, and would independently of any other EFTARG on any other EFT line for any other file.
4. As an alternative to an EFTARG option, suppose the entire EFT line, or at least the part of the line after the = sign, could be fetched using a new macro function, like
str = Get_EFT_Option()
So, if I had an EFT line like,
E:\**\*.txt = TXT, EOL LF
The value returned by the function would be "TXT, EOL LF"
Then, it would up to the macro writer to parse that string and act on it.
Finally, unless whatever method chosen were "dirt simple", there is no need to consider adding this feature now. It can wait until EFT extensions are ready and users have had time to test it and understand how it works.
Comments invited.
What is needed for that to happen is some means of conveying a "message" that the file is being opened in a different way. The question is, how to convey that message.
A few possibilities come to mind.
1. If the SUBARG profile setting were allowed as one of the new EFT operands, it could be used to pass a token, which could be fetched with Get_Profile$("SUBARG").
2. If a SET command were allowed as one of the new EFT operands, we could say SET name = value, and then fetch it with GET_SETVAR$().
While these ways would work, they have one disadvantage, which is that they set values permanently. Once a SET name is set, it is set globally. I am not sure how SUBARG would work under the current EFT extensions proposal. Would it be permanent or temporary? If it were temporary, then SUBARG might be the easiest solution and take the least amount of work.
Should (1) or (2) not be enough, it is possible some new means could be devised.
3. Suppose the EFT line allowed a new operand of:
EFTARG string
Then, there would have to be a new macro function like Get_EFTARG$(), or possibly GET_Profile$("EFTARG").
The main point is that the EFT argument would be local to that usage of the the given profile and EFT line. Its setting would be temporary rather than permanent, and would independently of any other EFTARG on any other EFT line for any other file.
4. As an alternative to an EFTARG option, suppose the entire EFT line, or at least the part of the line after the = sign, could be fetched using a new macro function, like
str = Get_EFT_Option()
So, if I had an EFT line like,
E:\**\*.txt = TXT, EOL LF
The value returned by the function would be "TXT, EOL LF"
Then, it would up to the macro writer to parse that string and act on it.
Finally, unless whatever method chosen were "dirt simple", there is no need to consider adding this feature now. It can wait until EFT extensions are ready and users have had time to test it and understand how it works.
Comments invited.
