EViews.com

Hi,

I am writing add-in and as one option I allow users to specify their own modified subroutine to perform as part of the add-in. The motivation is to allow users to easily incorporate their custom procedure into the add-in that performs many other functions. However, when doing this I am encountering limitations on what is allowed in Eviews. My first attempt was to include the subroutine only if add-in argument is specified, e.g.




This does not seem to be allowed in Eviews.

The alternative approach was to specify variable path from which to include subroutine and use default path if subroutine program does not exist in the specified location; e.g.




However, it seems that inclusion command cannot use strings, but has to have hardcoded path.

Therefore, the only solution I could figure out was to include default subroutine program from the add-in folder, which the user then would have to modify, i.e. user would not be able to use subroutine program of his own choosing.

Is there any suggested way one can allow conditional inclusion of subroutines or variable path of subroutine files?

Thanks!
CrisisStudent

Hello,

The include command is unlike other commands in that all includes are processed when a program is loaded, before the program actually begins executing. Consequently, includes cannot benefit from conditional statements or program variables. You can work around this limitation by splitting the program into two parts, a first part that writes the dynamic information (the desired include statements) to a fixed-name auxiliary program, and a second part the includes said auxiliary program and performs the rest of the work. As a working example, suppose I have two different versions of a subroutine, only one of which I want to include in my main program at runtime.

version1.prg:


version2.prg:


Unfortunately, I cannot write my main program as follows:


Instead, I will split my main program and have the first part use a text object to build and save a list of inclusions that the second part will intake.

part1.prg:


part2.prg:


Following this approach, your add-in should be to accept user-provided code without unduly limiting the user.

Thanks Matt, this should work!