More Subroutine Tabs

[KristanStewart]

Has there ever been talk of having more than one subroutine tabs? I was thinking something like 1-10 or 1-n. It would help in making logical groups of step groups and would save scrolling times.

It would also be neat if a name could be associated with the subroutine tabs on a per project basis.

Kristan

[kinook]

This is the first such request we've received. Go | To Step, Go | Subroutine, Step | Show | 1/2/3, Edit | Find (and their shortcuts) have always been adequate for us to navigate. But I can see where it might be useful for extremely large projects.

If your projects are very large, one thing that might help some (if you haven't already) would be to spend some time reducing their size by modularizing them (for instance, taking advantage of global subroutines [subroutines can call other subroutines], using built-in actions such as the Copy Files action for multiple %DOSCMD% copy steps, using solutions/workspaces/groups for related projects and using a single Make step in VBP to build them instead of one for each project, etc.). This would, of course, take some work, but could reduce project maintenance work going forward.

[KristanStewart]

Thanks for the shortcut tips.

I think our problem stems more from an organizational issue. We want to have the "project steps" tab just have simple clearly defined calls to the main script components.

example, the script has three main components

Checkout Source
Build Source
Package Source

We're trying to make the step layout obvious enough that someone who doesn't have a lot of experience with the script(s) can just open the script and check the steps they need and run the script. Thus the 'logic' of the script is hidden from them and when the script writer is away other people can still make builds without being overwhelmed by step options.

I think you are probably right that by just sorting and organizing the script would could accomplish most of our goal.

[kinook]

Another option for that would be to create your own front-end to the build process and launch VBP from that (ala the VisBuildPro\BuildLauncher and ObjectModel samples). Then the typical user wouldn't even need to use VBP directly.