Control variables are not local in a local subroutine
Posted: Thu Jun 13, 2013 9:06 am
Hi,
In a local subroutine, the control variables are not local, which may lead to problems if a subroutine calls another one which use control variables named identically. I think this is quite likely to happen if for loops are used in generic subroutines shared between different programs though the use of he include command (as was my case).
This undesirable behaviour is present in both EViews versions 7.2 and 8.
Here's a simple example:
The message box will display "a1", while if I remove the call to test1 in test2, it will display "b2". This means that the control variables in test2 are modified by the call to test1, even though test1 is declared local.
As a workaround, for the moment, I use the fact that the variables appearing as arguments are truly local and behave correctly, so I put the control variables as arguments. To keep the subroutine "interface" clean, I define a first routine with the expected arguments, and this routine calls a second one which includes additional arguments for the control variables. For example, the above example would become like this:
It works, displaying "b2", but it's both laborious and inelegant, especially when there is a larger number of control variables. Another solution could be to name control variables with long, complicated names that would effectively guarantee their uniqueness. I don't like that, because it increases much the risk of making a typo when entering the control variables' names, and since EViews will not complain and use simply use that 'new' variable, giving it a value of 0 or "", this could lead to errors that are not always easy to detect.
Best regards,
Étienne
In a local subroutine, the control variables are not local, which may lead to problems if a subroutine calls another one which use control variables named identically. I think this is quite likely to happen if for loops are used in generic subroutines shared between different programs though the use of he include command (as was my case).
This undesirable behaviour is present in both EViews versions 7.2 and 8.
Here's a simple example:
Code: Select all
subroutine local test1
%i = "a"
!i = 1
endsub
subroutine local test2(string %out)
%i = "b"
!i = 2
call test1
%out = %i + @str(!i)
endsub
%str = ""
call test2(%str)
@uiprompt(%str)
As a workaround, for the moment, I use the fact that the variables appearing as arguments are truly local and behave correctly, so I put the control variables as arguments. To keep the subroutine "interface" clean, I define a first routine with the expected arguments, and this routine calls a second one which includes additional arguments for the control variables. For example, the above example would become like this:
Code: Select all
subroutine local test1
call test1_args("", 0)
endsub
subroutine local test1_args(string %i, scalar !i)
%i = "a"
!i = 1
endsub
subroutine local test2(string %out)
call test2_args(%out, "", 0)
endsub
subroutine local test2_args(string %out, string %i, scalar !i)
%i = "b"
!i = 2
call test1
%out = %i + @str(!i)
endsub
%str = ""
call test2(%str)
@uiprompt(%str)
Best regards,
Étienne