The “default” values of variables don’t seem to be as useful as they could be. As I understand it they work like this:1) When a variable is created with a default value of X, its current value also becomes X2) Subsequently changing the default value to Y has no immediate effect3) The default value only comes into play again when the current value expires (for a non-persistent variable), or when a “Reset variable to default” action is explicitly called.The mistake I frequently make is in noticing the current value of a variable in the Project tab is “wrong”, double clicking it, and changing the default value - which changes nothing. I use almost exclusively persistent variables…Another product I’ve worked with had the same concept but seemed to work better in practice:1) When a variable is created with a default value of X, the current value is left as null.2) If a variable with a current value of null is accessed, the default value is returned instead.3) When another value has explicitly been set as the current value, the behaviour is like above - changing the default value has no immediate impact.4) Resetting the variable to default clears its current setting, making the default value be returned next time.In practice, default values would probably also work better if it was possible to reset variables to default values at design time, and if it was easier to view/change the current value of the variable (by double clicking in the Projects tab, rather than having to create a Watch then edit it).StevePS The reason I use persistent variables exclusively is to retain state if the build fails for any reason - if the variables lose their values when the build stops, it’s much harder to debug, and impossible to resume the build.
food for thought…
But one thing, you can decide when FinalBuilder resets variables. For example you can choose to not reset variables when Running Selected Actions, Running Selected Actions and Children, and Running from Current Action (settings are in Tools | Options | FinalBuilder category | Variables). Plus variables won’t be reset when you continue a build after it’s been in a paused state.
Interesting, didn’t know about those options. The first two won’t help much as I never tend to use the “run selected action” - instead, I tend to put a breakpoint after the current step, and just run from there - if that action passes, there’s every chance I’ll want to do the next one.
The third option might solve the painful situation of recovering after a stop - presumably unticking that box means that after a failed build, you can recover without losing state.
Steve
Yep... but only for the "Run from current action", it doesn't change the behaviour of the "Restart build from selected action".
“Restart build from selected action”? What’s that? I"m already confused enough with the various run options. All I’d really like is:
- Step: (from the “current” action if paused, or from the selected action otherwise)
- Run: (ditto)
- Run from start: (resets the project, and always runs from the very first action, even if paused)
You could easily achieve all the other combinations with breakpoints if need be. Except “Run selected actions” (without children), which is a bit weird anyway - why would you want to run several consecutive actions but not their children?
The biggest frustration there is that there is no easy way to start stepping from the selected action. You have to put a breakpoint on the next action, go back, run, remove the breakpoint, then start stepping.
Steve
PS sorry for the ranting, FB is almost perfect, really 
It's the button immediately to the right of Run - but only gets enabled when the previous build has failed (and it can only restart from the selected action in the Main action list).
Oh, same thing as “Continue from selected (Ctrl+F5)” in the Run menu?