Current problems associated with the use of this form:
1. Custom parameters are always persisted for the user, so each time the window is opened, the custom build params are not reset back to the project defaults. This means that if the project params change, the next custom build will not inherit the changes, often resulting in a failure.
example: we run a build sequence that (among other things) tags the project and publishes the build artifacts at the final step. By default, this step is actuall skipped by the tagging process as the default parameter on the project is set to "false". Obviously this is because we don't want to tag with each check-in.
However, to prevent us from having to have multiple, 99% duplicate build configurations the tag and publish process allows the user to simply override this value. Unfortunately, if the default publish locaion/share/server path has changed on the base project configuration or even template configuration, the changes are not reflected the next time the custom is run it is likely to fail or publish to the incorrect location.
To solve this problem, I suggest that we:
1. Add an option to the UI to allow the user not to save the custom parameters. Remember this option.
2. Add a link to allow the user to reset all params in one action, instead of forcing him to scroll and click each one individually.
3. Add a clear indicator next to the parameter to show that it differs from the default value (like you do in the environment variables when inheriting from a template).
Additionally, make the form resizeable - if there are many parameters it becomes tedious to have to scroll up, left, and down whenever one needs to edit it. Also, don't strip out newline characters (breaks any params sent to dotCover) - see http://youtrack.jetbrains.net/issue/TW-17001