Request: change the term "local variable"


Since Axure 9 is shaking things up, can we please get rid of the term “local variable?” The scoping of the variable (if indeed that is what “local” to refers to) is not at all descriptive of what the local variable is for, and I think it’s a barrier when learning Axure.

What about “widget variable?” Seems more descriptive, since the local variable either holds a widget property or a reference to the widget itself. If anyone has another suggestion, please chime in.


That kind of makes sense. I pretty much ignored local variables and created everything as a global variable only because I didn’t understand the difference.

That’s exactly my point, KavaKiwi:

Local variables deal only with widgets. You can’t assign a arbitrary number or text string to them. You can’t assign the result of an expression to them. A local variable can only refer to a property of a widget – such as its text or selected state – or to the widget itself.

Well, you can also assign a local variable to a global variable. WTF on that!

1 Like

Yes, agreed, Joseph. I wish Axure actually had local variables. Axure’s local variables aren’t variables at all.

I try to limit my use of global variables to less than a dozen based on the inefficient way that Axure stores them and the brittleness of re-using masters that reference globals in other projects or even in other parts of the same project.

The pattern I follow as a workaround is to calculate and store values in hidden widgets which I can then access later (like a global), but stay local to a set of widgets in a master.

Widget variables would be great if they could just be real Widget variables. The best I could get from “Local Variables” was only within the cases. In order to get functional widgets (e.g., a number pad) whats needed are Widget variables that work between the other events and actions within the widget and NOT defined at the Project level.


Local variables are defined within commands as well as conditions and not at the project level like global variables are. (You won’t see local variables in the global variable list.)

You can use local variables in a library widget, for example, and when you drag that widget into whatever project, the local variables will come along with it.

There is a workaround of sorts if you need widget variables. You can create a hidden widget to act as a variable for another widget. Then you can reference any value stored in the hidden widget

For example, imagine you had a repeater with items for sale. Let’s call each item a SalesItem. Each SalesItem has an image, price, icon and descriptive text. You can store values in hidden widgets within each SalesItem to store how many items are in inventory, or the original x, y screen position, or whatever you want. Those values can then be referenced and changed in formulas from inside or outside the repeater.

So you can use a hidden widget any time you need a variable within a widget, repeater item, group, or master.