#1
|
|||
|
|||
some VBP eval issues
I'm evaluating VBP as a possible replacement for FinalBuilder. I can see that both products have relative pros and cons. The main con (for us) against FB is that it doesn't provide a COM interface and this is why we're evaluating VBP. So far, these are my VBP impressions while trying to migrate a FB project to VBP...
1. Help is too superficial Help often doesn't go into enough detail to actualy help me solve my vbp development questions. However, the fact that I'm grasping for information in the first place probably indicates a problem for what should be a fairly simple to use 'visual build' application. 2. Lower level Actions than FB I'm puzzled why I should be forced to included snippits of macro code in an action to do something as basic as checking that a file exists. FB has a complete action for this - quick and easy to use. 3. Program constructs like IF / ELSE missing in VBP Sure, you can kind of reconstruct IF / ELSE using those 'GROUP' actions in VBP but it slows development down a lot. Furthermore, the resulting actions are a devil to debug. I had a situation where the vbld_FSO.FileExists function wouldn't return the correct status unless there was a single variable/macro to represent the file/path instead of a mixture of variable/macro and text. So, this would not work: [vbld_FSO.FileExists("%BuildFolder%\config\config.i ni")] whereas this did work : [vbld_FSO.FileExists(%configFile%)] along with the double quotes assigned as part of the configFile variable\macro (which is the way I saw it done in one of the sample projects). I guess this is fine for those who enjoy pain but I don't. 4. Complicated options for running projects/steps FB is a joy compared to VBP in this respect. In FB, it's much more intuitive with simple options to 'run' the project, step, step + children and so on. A small example... In FB, if you select the 'Run' option, it will always run the project cleanly from the beginning unless you have inserted breakpoints. In VBP, the behavior of 'Build'\F7 is quite different and another option has to be selected to reset the project. Not a big deal perhaps but why design an app to be more complicated than it needs to be? Also, I think it's confusing that VBP refers to 'Build' when it should state 'Run'. Logically speaking, I 'run' a 'project' to do a 'build'. 5. No variable inheritance apparent in sub-projects??? Not sure about this as I'm still trying to understand what is or is not available to me in VBP with regard to variable inheritance. Are the project Parameters the only way to pass variable information to a sub-project? Do the parameters work exactly the same in the sub-project as macros/variables? Also, why are variables called 'macros' in VBP??? 6. Generally more difficult to do simple things in VBP than in FB On the plus side, VBP has a much nicer GUI interface than FB, which is gludgy in comparison. VBP also has the COM interface and what appears to be a well presented Object model. If only VBP could 'borrow' some of the nicer features from FB it would be a near perfect product. Clive |
|
|