Name shadows another variable

[Peter Haworth]

On Fri, Jun 27, 2014 at 7:08 PM, Mark Wieder <mwieder at ahsoftware.net> wrote:

> So... ensure that variable preservation is unchecked, change the name
> of the variable to something without a conflict, compile the script,
> and save the stack. I think that should clear up the problem for this
> stack. Since I never use variable preservation and always have strict
> compilation enabled I haven't run into this problem, and can't say for
> certain whether this will do the trick, but it makes sense to me that
> way. I also haven't looked to see where variables are being stored,
> and maybe someone else has a better sense of that.
>

Hi Mark,
Thanks for the idea.

I'm not sure I fully understand your explanation but I do have Variable
Preservation turned on.

It's unlikely there's a clash of variable names in a different scope since,
like most of us, I use a naming convention for global, script local, and
handler local variables.  Having said that, the stack in question is one
I've just started working on again after a long break and I may not have
been as "educated" about variable naming conventions when I last worked on
it :-)

I tried what you suggested. After changing the name of the variable in
question, the error went away for that instance of the variable  but the
same message came up for the same variable name in a different handler.  At
least it's consistent!

Following that, I just continued changing variable names until the error
stopped occurring - there were a couple of other variable names that were
used in multiple handlers - and now all seems to be OK again.  Not all
variable names that were declared in different handlers were flagged by the
way.


Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>