I'm not sure if this is a bug or I just don't understand, but here's what happened:
1) Created variable "buildroot" with default value "c:\testbuild\b1", persistent=true
2) Did some builds
3) Changed default value of that variable to "c:\testbuild\b3". When I hover the mouse over the variable in steps that use it, it definitely comes up with this new value.
4) Did some builds - the old value (c:\testbuild\b1) is still used
Any idea why that would be the case?
I now unclick "Persistent" and from the next run, it takes the new value into account. Is this the expected behaviour? It doesn't quite seem to match the documentation...?
Steve
Hi Steve,
There’s a bit of a catch for persistent variables - the “default” value is not the current persisted value. To change a persistent variable back to default, you need to use a Reset Variable to Default action.
When you look at a variable value at design time, you see the “default” value not the current persisted value. You can change whether you want to see Default or Current values at design time by going to Tools -> Options -> FinalBuilder -> Variables.
If you want to change the current value of a Persistent variable (not just the default) from inside the IDE, the easiest way is to go the Watches tab, add a Watch for the variable, and then right-click it and choose Modify Variable to change the current value.
I’ll look into whether we can add a way to edit persistent variable current values from the Edit Variables dialog, as well.
Regards,
Angus
Hmm, something about the way they work just isn’t intuitive to me at all. It could be because I’m used to the way another, vaguely similar, product handles them which is basically:
* Variables have a default value and a current value, and, simplifyng slightly, a "persist/don’t persist’ flag
* At the end of a session, if the variable is non-persistent, its current value is effectively returned to the default value. (in reality, the current value is set to null, and subsequent accesses to the variable retrieve the default value instead)
Under this mindset, I’ve created a “persistent” build number variable, BuildNum (everyone must do this). My project starts by incrementing it then shows it in a messagebox. However, something about it isn’t working right. It incremented its way up to 1005 over various builds, and now it’s back to 1003 (without closing/reopening the project).
I also notice that if I close/reopen, the value is lost. What’s the right way to do this?
Steve
I’d suggest that the better way to handle version numbering is to use a PropertySet that you load at the beginning of your build, increment it if/when required, and then save it at the end of the build if required.
hth.
You’re probably right. They just look a bit limiting in that there are four defined types, each of which has defined property names - doesn’t look like you can add/remove fields, or change the name of any. Probably the way to go though.
Steve
Hi Steve,
I can see how you find that way of thinking intuitive.
I can’t explain why you seem to be losing persistent values. They should be saved to a .fbv file in the same directory as the project (although the file may not appear until the project is closed.) The file is in plaintext, so you should be able to just open it in Notepad and see what the current stored values are.
Regards,
Angus
It turned out to be a bug (which I filed in the relevant forum) where the “expose as environment variable” was causing it to be reset. Everything is ok now 
Steve