I've had them show up in build directories and on the desktop.
The one on the desktop had the RSS feed html in it, but turning off RSS feed doesn't keep the directory from coming back. One time it had a temp file that started with "Nexus" in it (I didn't capture the full name, unfortunantly).
The ones in the build directories are always empty.
They appear to be related to an action to export a copy of the log as HTML to a fully-qualified path that is composed of variables.
I’m going to take an educated guess that you are modifying your TEMP environment variable, as all these files and folders you mention should be created in the temp folder.
Yes, that’s what was causing it. I found it after you pointed that out. It was a hack on a test I was conducting in an action list, because there isn’t an obvious way to create a temporary, scratch variable to store some intermediate results.
I found that creating additional scratch entries in the Action List parameters section suffices for what I needed to do.
The variable usage mode (or more accurately, the confusion in the documentation on what’s available)l is so far the only thing I’ve got a gripe about with FinalBuilder. In the other areas I’ve worked on, it’s been pretty great!
And I've only had one cup of coffee this morning :)
As for temporary variables.. it's only the R&D list to investigate the possibility of creating local variables, I haven't gotten to it yet so I'm not sure what the semantics will be (if at all), haven't really thought it through yet, so I'm open to suggestions.
And I'm getting ready to open a nice bottle of wine once I'm done tonight!
I found that adding them as action list parameters works well so far.
There's apparently nothing invalid or checked for about defining parameters that are not set by the caller, and they exhibit the desired scoping rules: available within the action list where they're defined, and unavailable once that action list has returned.
So as long as it's valid to have parameters defined that are not set by the caller, they should be just fine. If you do add the requirement that they be set by the caller, then I'd recommend adding a separate block to define 'local variables' that behave the way parameters do now.
I don't see any reason to require that action parameters be set by the caller, if they are not set they will just be empty, which is a valid state for a variable.
We field a lot of support requests about variable usage etc, so it's definitely an area I want us to focus on in the future.