Page 1 of 2

DefineVar Command - Local Scope

PostPosted: Fri Mar 02, 2012 10:06 am
by Enigman
The new DefineVar action has an option to make a variable "local". It defines local as: "The variable exists only while the current script is executing. When the current script ends, the variable is automatically deleted."

What this doesn't specify is whether the "current script" is the top level script, or whether local variables defined in subroutines stay in the subroutine. I hope it is intended to be the later.

Does anyone know?

Thanks.

PostPosted: Fri Mar 02, 2012 12:01 pm
by Neosoft Support
Variables defined as local are only visible within the script that created them. Only global variables are visible to subroutines, functions, etc.

PostPosted: Fri Mar 02, 2012 12:50 pm
by Enigman
... oooo kay, but I want to do this the other way around. Can I define a variable as local within a subroutine, and have it stay within the subroutine?

PostPosted: Fri Mar 02, 2012 12:57 pm
by dec
Hi there,

Enigman wrote:... oooo kay, but I want to do this the other way around. Can I define a variable as local within a subroutine, and have it stay within the subroutine?


I'am not sure, but maybe a possible workaround can be to set the needed subroutine variables, and then, before the subroutine "return", simply clear the refered variables. So when the subroutine is executed, any related variables are put in the limb.

PostPosted: Fri Mar 02, 2012 1:21 pm
by Enigman
One can do that without the DefineVar command simply by doing:

Code: Select all
:MySub

SetVar "[Usethisinside]" ""

..do stuff with [Usethisinside] ...

SetVar "[Usethisinside]" ""

Return

I was hoping that the DefineVar action created local scope variables that knew the internal boundaries of the subroutine. The above reply from NB implies that it is the opposite, that vars defined local outside the sub stay outside, but vars defined inside the sub possibly leak out in the calling script.

That further implies that the recognized boundary is the GoSub action, and the Return command is not seen as a boundary. If so, that also means that variables defined inside a subroutine can be seen by other subroutines.

In other words, the true script boundary would be the contents of a given script editor, and only the GoSub or Call actions block vars defined as local within the script editor screen.

Clarification from NB? Dave?

PostPosted: Mon Mar 05, 2012 11:41 am
by Neosoft Support
I'm not sure what you're looking for, but variables defined as "Local" are only visible within the script where they are declared. If you define a local variable within a subroutine and jump to another subroutine, the local variable will not be visible within the second subroutine. If you need a special limited scope variable, then (per your example) you can create a global variable and clear it when no longer needed.

PostPosted: Mon Mar 05, 2012 11:59 am
by Enigman
What I was looking for is the definition of what NB considers the "edge" or "boundaries" of the "script where they are declared". You're saying that local vars in one subroutine are not seen in another subroutine. That's good. My question was if I declare a local var in a subroutine will it be seen by a calling script. I'll infer that if subroutines cannot see each other's local vars (even though they are all in the same editing screen and therefore stored in one object) then reasonably one can assume that a calling script will not see subroutine local vars.

Thanks. Great addition to NB!

PostPosted: Mon Mar 05, 2012 3:01 pm
by cp4w
interesting.
I didn't realize that this works in subroutines.
Now I see that even within buttons and I guess other objects that you can define a local scope variable.

If my understanding is correct, this will only be seen within the object but not within the called subroutine from that object.

PostPosted: Tue Mar 06, 2012 11:35 am
by Neosoft Support
If my understanding is correct, this will only be seen within the object but not within the called subroutine from that object.


Yes, that's correct.

PostPosted: Tue Mar 06, 2012 11:57 am
by Enigman
Given that we now have this great DefineVar command, does it also make sense to provide a way to pass data directly into a subroutine, other than using a bunch of SetVars on global variables ahead of time?

Something like: GoSub "sub_name" "comma_separated_list_of_text_or_var_names"

Then inside the subroutine there could be available a NB defined local array like [Param1] [Param2] ... thru ... [ParamX], one for each input.

The subroutine could still return data using global variables as needed.

That would be useful and still not be turning NB into "Delphi Lite" :)

PostPosted: Tue Mar 06, 2012 12:00 pm
by Neosoft Support
Given that we now have this great DefineVar command, does it also make sense to provide a way to pass data directly into a subroutine, other than using a bunch of SetVars on global variables ahead of time?


That's something that I've been thinking about too. It would greatly expand the usefulness of subroutines.

PostPosted: Tue Mar 06, 2012 12:10 pm
by dec
Hi there,

Enigman wrote:Given that we now have this great DefineVar command, does it also make sense to provide a way to pass data directly into a subroutine, other than using a bunch of SetVars on global variables ahead of time?

Something like: GoSub "sub_name" "comma_separated_list_of_text_or_var_names"


What about NeoBook functions? Functions can receive params...

PostPosted: Tue Mar 06, 2012 12:43 pm
by Enigman
dec,

I know, but given the DefineVar command, the added capability for internal subroutines makes sense.

I used to use external functions, but I don't any more. Being external to the pub file, functions are something else that needs to be managed. For me, my apps are all widely dispersed in "genre", so my functions were rarely reused in other apps.

I also no longer use third party plug-ins. My apps tend to be around for long periods and when support for third party plug-ins dries up, then I'm hosed.

I prefer to have all the functionality I need in native NB, hence my suggestion. :wink:

PostPosted: Tue Mar 06, 2012 1:27 pm
by dec
Hi to all,

Enigman wrote:I used to use external functions, but I don't any more. Being external to the pub file, functions are something else that needs to be managed.


I think is not too hard to prepare a "BATCH" file in order to maintain the functions of a publication well managed. So you can copy, move, backup the functions definition files, etc. But of course if you don't want to use functions, will be ok: it's your choice. The same if you don't want to use plugins, it's your choice.

To me functions can be very good, to much if you want to pass arguments in order to achieve certain task. Functions allow to do this. Functions allow to isolate reusable code in a "black box" manner. You can pass to the functions the appropiate functions some arguments and give the appropiate result. Rules!

I don't discard the use of functions, on the contrary, I think can be very very good. ;)

PostPosted: Tue Mar 06, 2012 1:55 pm
by Enigman
All good and valid thoughts. To each his own.

However, I still think that parameter passing to subroutines would be a good thing, regardless of how or whether functions and plug-ins are also used.

Dave? Could this end up on the do-list for future revisions?

Thanks.