Chris wrote:
Thanks for the report. If I understand correctly, the crux of the problem is in bold below:
Fixed StringSplit when used inside a function so that it always creates a local array when OutputArray0 is local, even if OutputArray0 also exists as a global.
Corrupt: I think this issue is specific to StringSplit; it doesn't seem related to anything else involving globals/locals or that other topic you mentioned.
Thanks.
Hi Chris. I might be misunderstanding the logic behind the design (and possibly your post) but what I was trying to point out is that it seems logical that using a non-dynamic variable name in the SplingSplit line should create a local array unless the array was specified as global at the beginning of the function. In other words... instead of "
always creates a local array when OutputArray0 is local" it would be more consistent if it was "
always creates a local array unless OutputArray0 has been declared as global". This seems to be how the MsgBox line is interpreted. Here's another example. Temp1 and Temp2 get created as local in the function since they were referenced by name but Temp0 was not created as local when referenced by name. None of the variables were declared as local or global so it seems to be inconsistent (unless I'm misunderstanding the issue).
Code:
temp0=1
f()
MsgBox main`ntemp0 = %temp0%`ntemp1 = %temp1%`ntemp2 = %temp2%
return
f()
{
x = ab
t = temp
out = f()`n
StringSplit,temp,x
MsgBox % out . "`ntemp0 = " . %t%0 . "`ntemp1 = " . temp1 . "`ntemp2 = " . temp2
return
}
Login
Register
FAQ
Search
vPhiLho 