Hi. First time here. I looked around, but couldn’t find anything on this problem, so I thought I’d ask…
So, here’s my situation; our applications come in one of four build varieties: desktop, service, handheld, or delphi. Each of these build types has it’s own special snowflake of a FB6 project, and I run them selectively from a shell project. In the shell, I have a variable called %ApplicationName% that is a prompt from a sorted list; the shell project then goes through a series of if/then/else statements to decide which of the four types the selected app is, and then calls that project. The shell application is working fine, and is very convenient.
We recently found an error that required changes to our common libraries, and subsequently, we need to rebuild a large portion of our application collection. I am trying to modify the shell project to do this, and I thought I’d found a solution using a combination of the enhanced variable prompt and the list iterator. I set up my variable to be called %ApplicationList% and used the check box prompt to allow selection of multiple application names. Each string option in the list is followed by a comma (,) so that I can use the comma delimiter option in the list iterator.
When the project runs through the first time, everything goes smoothly. However, once the project gets to the second application name in the list, I run into problems. As best I can tell, a newline character is being added before the desired string.
This is how the Build Log should look when the project path is being set. The screenshot was taking from our working shell project.
This is the same section of the Build Log when the project is called on the second item in my string list variable; notice the application name on the line following the path.
I’m not sure what I’m doing wrong or what I need to do differently, but any help would be greatly appreciated. It would be a great convenience if we could rebuild an entire application suite without having to be present to start each application build.
Also, I have added watches to both the %ApplicationList% and %ApplicationName% variables; they appear to be correct in the watch, just not in execution. For example, if %ApplicationList% has a value of ‘Car Manager,Boring Mill,Final Inspection,’ and the multiple build shell project is on the second iteration, %ApplicationName% will show in the watch as ‘Boring Mill’, but when the shell calls the project to build the individual app, the string doesn’t return true on if(%ApplicationName% == ‘Boring Mill’).
Thanks in advance for your help.
-Joe
Can’t seem to get the images to show up right.
The %ProjectPath% string should look like this:
C:\Projects\SuiteName\ThisApplication
However, when my iterator hits the second item, the %ProjectPath% string gets set like this:
C:\Projects\SuiteName<br>ThisApplication
-joe
Hi Joe,
Thank you for the detailed post. Helps us a great deal in working through the issues your seeing.
So from what I understand your script is doing the following;
- %ApplicationList% holds a list of project paths for solutions to be built.
- When iterated %ApplicationList% has two entries where you expect to see one.
- %ApplicationList% is comma separated, and is iterated using the List Iterator with the comma separator set.
- %ApplicationList% is built up from options set in the Enhanced Variable Prompt.
- When inspected/watched %ApplicationList% has the correct comma separated list before iteration.
- Your using FinalBuilder 6 (version not listed)
If I have all the above correct, there might be an issue with the version of FinalBuilder 6 which your using. Trying the above here on the latest release of FinalBuilder 7 I get the behavior your expecting. I would suggest downloading a trial of FinalBuilder 7, install it on a VM/test machine and run the scripts in question with it. Upgrading scripts is done automatically, and saved to a fbp7/fbz7 file extension.
The only thing that wasn’t clear to me was how the list value was constructed. This is typically where error can be introduced as line endings might seek in unexpectedly. I have ruled this out though as you have stated the list variables value under a watch looked correct just before iteration started.
Jason,
Thanks for your reply. All correct, except maybe the second item; if I have a list of any size in %ApplicationList% and then iterate through it (storing the list items to %ApplicationName% for each iteration), the first run correctly pulls out the string, but the second run seems like it’s adding a new line character to the second string in my list. I assume this will continue to happen on the third, fourth, etc. iterations, but the project never makes it through the second. I will try to test that later on. I’ll also look into the FB7 trial you suggested.
Example of above:
%ApplicationList% = ‘App 1,App 2,App 3,App 4’
%ApplicationName% gets stored as:
1st Iteration: ‘App 1’
2nd Iteration: ’
App 2’
Thanks again for your help, Jason
-joe
Jason,
I’ve got an example project worked up that illustrates the issue I’m seeing in FB6. Also, I can confirm that the new like character, or whatever it is, is getting inserted into all list iterations after the first. Let me know if there’s a good way to get the sample project to you (2MB, so I can’t attach it here) if you think it will be any help.
Thanks
-joe
Jason,
I can also confirm that I’m still running into the issue in FB 7.0.0.3036. I must be doing something wrong, I just can’t imagine what.
-joe
Found a workaround! Using the ‘Set Variable’ to trim whitespace from both sides of string action immediately after the ‘List Iterator’ action allows the 2nd and subsequent runs to assume the proper value for %ApplicationName%. Still not sure why the extra whitespace was being added to the string, but this makes it work as I meant for it to.
-joe
Hi Joe,
That’s very interesting. Feel free to send me a cut down project which replicates the issue if you wish. Just mailing it to support and I can pick it up from there. If there is indeed something which FinalBuilder is doing unexpectedly we should get it fixed.
Either way, great to hear you have a working solution.