Whenever you "step" with F10, you might as well show the live log for that step. Performance isn't an issue, and you're likely to be debugging, so it would be helpful.
And while we're at it, a "step over" function would be really nice. It would run the current action and all its children (and if it's a "run action list", the entire action list) in one go, then pause again.
Also a way to "step from here". Currently you have to set a breakpoint on the next line, go back, run, remove the break point, then step. At the least, IMHO if you "run from current action" and there's a breakpoint on that action, it should immediately pause before running anything.
Thanks for the suggestions. I think Live Logging in the way you describe would probably be a bit confusing in terms of consistency (a feature which turns itself on and off.) However, I have another feature in mind which will more or less give you what you’re after, anyhow.
We’ll look into Step Over. I’m not quite sure what you man about “Step From Here”, though. Do you mean to re-run an action which failed, and then step to the next action in the project?
1. You run the build, it fails at step 55 because you made a mistake at step 54. 2. Select step 54, press the hypothetical “step from here” button 3. FinalBuilder runs step 54, then pauses again. 4. You press step again, it runs 55, pauses… 5. Everything seems to be ok, you press run…
While I’m dreaming up features, it might be useful in certain contexts to have it so that every time you click a step in an action list, the build log automatically filters by that action.
While I’m dreaming up features, it might be useful in certain contexts to have it so that every time you click a step in an action list, the build log automatically filters by that action.
This would be useful, and it’s something we considered when we did the “Filter Log by Action” feature in the first place. The “gotchas” are knowing exactly what contexts to do that in, and also that filtering logs by action is perceptibly slow (not really slow, but slow enough that you don’t want it happening every time you click the mouse.)
A simple context would be when you’ve checked a “Constantly filter log by action” checkbox
Depending how slow it is, you could: a) Do it after a slight delay (say, 0.5s), so you could still quickly click/cursor around b) Have a manual ‘refresh’ button on the log… c) Have an option where only the most recent run of that action is shown (rather than all executions…)
Something we can do very easily is map a key binding for “filter log by action”, that way it’s one keystroke instead of a context menu to get it going.
Once I’ve done that I’ll do some speed tests to see if it’s viable to have it happen on each click, but I suspect it’ll be annoyingly laggy (it’s a 0.25-0.5s pause each time if you have a “real world” size log, because it has to round-trip to the log file database.)
