Version 1.50 released

Build Automator news Send feedback »

We released version 1.50 on August 5. Time got away from us so I never got around to post about it here or on the forum. I will try to make ammends for that.

I described version 1.5 pretty thoroughly in my last blog and there were no further changes or updates made to the install after I posted that blog.

We will be releasing a new minor build tomorrow, Monday August 18. It includes two fixes for regressions that were introduced with fixes in last build and that cleans up couple of issues. The first problem was that under certain circumstances the Action item list could get corrupt. It didn't affect the data, just the list. The other one was that if the name of a Project Item was changed it would not trigget the "File | Save" option or the Save button to be enabled. However, when closing the project window it would correctly indicate that the data had changed and prompted for saving. Somehow one of the action files was accidentally removed from our source during a cleanup process - manual cleanup I might add&#59;) - and we have included it in the new build tomorrow.

Tomorrow's build also has one additional action - Terminate Script Execution. This is a very handy action as it allows you to stop the script. It can use a condition so you can conditionally terminate the script, for example if a certain button is pressed when using the Message action. If no condition is specified, the script will simply terminate. This can also be handy when debugging scripts and you only want it to execute upto a certain action item.

We have also added a validation of the Maintenance Plan, which was causing confusion. When you enter the Maintenance Plan it will now be automatically and immediately validated and the expiration date shown. The Maintenance Plan is verified when the program starts if it hasn't been verified and also when you update the Maintenance Plan. We have tested this in all possible ways we can think of. If you run into any problems with this please post on our forum and we will fix it right away:)

Finally I want to add that on a personal note we are going to be moving to Port Angeles, Washington and in fact we signed papers last week to sell our house here in San Antonio. The buyer has until next weekend to decide but if everything goes according to plan we will be moving out on September 18 and heading to Port Angeles. It will take us about a week to get up there. I don't expect this to affect our schedule since I expect to have the September build ready before we move and then we will probably not release another build until early November. If we have to delay the September build, it should only be until the very beginning of October.

-- Arnor Baldvinsson

More about next version

Build Automator news Send feedback »

After a week of very intense work we have completed all the programming and will be finishing up the documentation tomorrow. The new version, 1.5 will be out Tuesday morning if nothing unexpected comes up.

The FTP upload is complete and works great. It's fairly simple and only allows uploading of files to a single folder on the server. Later on we will add more powerful action that can upload subfolders as well. The server connection information is set up separately so when you create a new FTP action, you simply select the server from a dropdown list or click a button to view and update connections.

The FTP upload action is a bit different from other actions because it allows you to test the action right when you are setting it up. This way you can make sure that the connection is correct and you can optionally upload the files also to make sure that everything is put in it's place. You can optionally set the files to be uploaded as lowercase.

We added a very useful feature to the "Clarion compile" actions that allows us to grab any errors from the compiler window and automatically include them in the Build Automator log. This screenshot shows the results of compiling a Clarion app that resulted in 4 compiler errors. The Build Automator log now shows you what module is involved, what lines and what errors! This makes it so much easier to spot problems during unattended compiles. Big thank you to Clarion guru Larry Sand for helping me out with some screen scraping code that worked absolutely perfectly for this! And thanks to one of our Clarion users for suggesting this on the forum last week:)

The last thing we have worked on is a very powerful "Delete Files" action. It has several very powerful options which I'm going to discuss just a little bit.

You can select a single file or you can select a folder. If you select a file, then only that one file would be deleted, but you can always modify the selected file/folder to include any valid wildcards. For example C:\Temp\*.* would apply to all files in the C:\Temp\ folder and C:\Temp\*.txt would apply to all *.txt files.

You can Include Subfolder, which will then recursively delete files in all the subfolders under the selected folder. For example for C:\Temp\*.* it would delete all files in C:\Temp\ and any subfolders that might exist under the C:\Temp\ folder.

The Build Automator can prompt for confirming the delete process. Note that this will halt unattended builds and the program will wait until the question is either confirmed or declined. So if you are running unattended builds, we suggest that you uncheck the "Confirm Delete" when you are satisfied that it is correctly set up and it works correctly. The message will tell you how many items there are available to delete.

The deleted files can optionally be sent to the Recycle Bin or it can be skipped. Skipping the Recycle bin is considerably faster but then the delete process is premanent and cannot be reversed. Use at your own discretion.

During deleting process every error is logged into the Build Automator log. The log gives you extensive error information directly from the operating system. However you can optionally select to log every file that is deleted. This is a good option to have when you are checking things out and setting things up to make sure that the files that you expect to delete were deleted and nothing else.

Normally Read-Only and Hidden files are not included in the delete process, but you have an option to include Read Only and Hidden files. Doing that adds a small subprocess that changes the attributes on the files to normal/archive before the delete process runs. System files are never included in the delete process. If you have needs to delete system files, please let us know and we will add that as an option. Files that are locked or in use by other processes cannot be deleted. They are reported in use and skipped.

If you are using the *.* wildcard in your delete process you can also opt to remove all the subfolders. This option is only available when you use the *.* wildcard as that's the only way that all files are removed from all subfolders. If you need to completely remove a subfolder but can't use the *.* wildcard, we suggest that you set up a second "Delete Files" action that deletes the subfolder and all of it's files.

Similar to the FTP Upload action, you have an option on the "Delete Files" action window to click a button to bring up a view of all the files included in the file search and would be deleted by the process. This makes it easier to check what files are included with the different wildcards and also if there are files in subfolders etc. that match the wildcards.

Tomorrow, Monday, we will finish up the documentation and the install and the new version will be out Tuesday:)

-- Arnor Baldvinsson

Moving on - next build on the horizon

Build Automator news Send feedback »

It's been quite a while since I posted on the blog! We have been so busy that time has just flown!

As some of you may know we are moving to Washington State. So we have been working on getting our house ready to sell and we decided to take some time off to work on that. That meant that other things slowed down in the meantime. But the house is now on the market and that means we are back to work:)

For the past week I have been working very hard on a new version of the Build Automator. We have a lot of exciting stuff that we are including in this new build and I'm just going to mention the highlights of what I've been doing.

First of all we have completed an update to the "Call MS-Build" action so that it can now work with Delphi 2007/RAD Studio from CodeGear. For this we needed to do some research into setting environment variables as the RAD studio does that when it shells out to the command line console for manual calls to MS-Build.

We have also completed new actions for Setup Factory and MSI Factory from IndigoRose. Every thing looks good for both actions and we have not run into any problems at all with either product.

The Message action got a complete overhaul. You can now specify what buttons to show on the message box and also which one of those buttons (or none) should be a default button. The button value is stored in a variable that you can then use in conditions or whatever. Each button has it's own value in the system variables and you can use those to compare with in action conditions.

Today we completed a "Call DLL" action that is extremely powerful as it allows the Build Automator script to call function a dll and pass upto 6 parameters to the function. Currently the parameters are limited to char* parameters for C or CONST *CSTRING in Clarion since the Build Automator's data is entirely based on CSTRINGs. We may add support for multiple data types later on. The function must return an integer value which is passed on to the $ExitCode$ variable for you to use in later actions if needed. If you need to pass data from your dll to the Build Automator script that cannot be confined to an integer, you could use an INI file or the registry to pass data back to the Build Automator.

Just because the datatype is a string doesn't mean you can't use if for numbers, they are just passed as strings so you may need to run conversion functions on them to convert them to the proper datatype.

This action opens up all sorts of possibilities for extensions to the Build Automator scripts and makes it a very powerful tool. If the Build Automator doesn't have what you need, you can simply create a DLL to do it and call it from the Build Automator!

The last thing we are working on for this new release is FTP uploads. This will be a simple action to start with that will simply take a list of files and upload them to a folder on a specified server. We plan on having this working today and finished off by tomorrow morning.

We also have a couple of smaller actions that we are working on. We have also improved the logging quite a bit so that it now shows the project line numbers and action item line numbers and the same information as the project action list in the program shows.

We are very excited about this new release and hope you are too:)

-- Arnor Baldvinsson

Plugin demo

Build Automator news Send feedback »

We had hoped to get some demonstration of how to create plugins for the Build Automator out before the end of the week but that will not happen until next week. We have been battling air conditioning problems in the office since Wednesday and working in over 30°C/85°F is not exactly inspiring so things have been quite slow:-/ We had to replace the coil in the indoor unit and we are finally getting a guy today to do that:)

Even so, we have been pushing through and have made some changes and improvements to the IDE. One of the things we got reported was that if the Build Automator was used as a part of a batch file that was run overnight from a schedule it would halt because the Build Automator showed the logfile and did not terminate. So we added a /NL parameter to the command line which can be used with the /E paramter to Not show the Log file.

We also discovered that if no items were in the Action Item list, it was still possible to execute action items, update action items etc. which should not have been possible. We have gone through Project Window to make sure that options are not available when they shouldn't be. This will make the IDE safer and easier to work with.

With the small fixes and stuff that we have made we will probably kick out a hotfix build next week to keep everybody upto date.

-- Arnor Baldvinsson

Combining the Developer and Standard Editions

Build Automator news Send feedback »

As we released the final build of the Build Automator last week we posted that we had combined the Standard and Developer Editions before the final release. We feel that this may need some more detailed explanation.

The released Build Automator includes everything that the Developer Edition was designed to have. That includes the ability to create and use your own plugins. But instead of having the Developer Edition including everything we can ever come up with, it will include basic set of actions. Specialized actions that are not of general use will be provided in separate plugins that we will make available for sale. The price for those plugins will vary depending on development time and other factors, but we see the prices range from perhaps $20 to $100 - could be more, could be less.

Lets look at an example: For Clarion developers there are already two actions in there to compile Clarion applications. One is for a single application only, the other one is for multiple applications. This is an example of a basic functionality that would be found in the standard action set for the Build Automator. Originally we had posted plans to add actions to register templates, run utility templates etc. and this was to be part of the Developer Edition. Now rather than having to purchase the Developer Edition you can buy the Build Automator and then buy the Clarion plugin.

If you don't need the Clarion plugin, you still have the ability to compile your applications in the Build Automator. We will provide a plugin that can export applications and dictionaries, execute utility templates, etc. etc. that are all very Clarion specific. Programmers using other languages will not find much use for the Clarion plugin. Clarion programmers on the other hand might find such a plugin very useful.

We don't feel that this diminishes the value of the Build Automator in any way - quite the contrary. Now you can buy the software which will provide you with the basic functionality but if you need some other specialized actions, you could develop them yourself or possibly purchase them from us or other BA third party developers.

The reason why we made this change before the final release was simply that we didn't feel it was right to stuff everything into the Developer Edition. The reason why we developer the Build Automator so that it could be extended with external plugins was flexibility. I did not see that we gave much flexibility with just two different editions of the software. I see this benefitting both us and our customers as being both more flexible and more attractive financailly for both parties as well as our customers will only be paying for what they need rather than paying for what they need and then all kinds of specialized stuff that they may not need.

If you have any questions about this, please don't hesitate to contact us:)

-- Arnor Baldvinsson

Contact / Help. ©2017 by Arnor Baldvinsson. free blog tool / green web hosting / FP.
Design & icons by N.Design Studio. Skin by Tender Feelings / Evo Factory.