After working with all three add-in types (Access, VB 6, and Visual Studio 2005), my conclusion is that Access add-ins have advantages over both VB 6 and Visual Studio 2005 add-ins, at least if you are running Windows XP. One of the most significant advantages of Access add-ins is that they are themselves Access databases, and this allows you to copy database objects from the code database to the calling database. If you need forms in a VB or Visual Studio add-in, you have to create them from scratch as VB or Windows forms; reports (in some versions of VB), can only be created using Crystal Reports. Another advantage of Access add-ins is that only an Access add-in can create a wizard or builder. And finally, Access add-ins use VBA code, so you don't need to learn a new programming dialect, just a few special techniques.

However, if you want your Access add-ins to create custom Ribbons, there are some roadblocks at present. Getting the custom Ribbon to display, and to run add-in code, may require so much time spent in uninstalling and reinstalling the add-in, unloading and reloading the table, and closing and reopening the database numerous times, that you get totally frustrated in trying to get the add-ins custom Ribbon to display (and its buttons to work). By contrast, Access add-ins that create menu add-ins and property builders work just fine once they are installed, and so do Ribbons and buttons created by VB 6 and Visual Studio add-ins.

When you need to put a button somewhere other than on the Add-Ins tab, and you don't want to fiddle with getting Ribbon buttons to work from Access add-ins, you can create a VB or Visual Studio add-in — both work very well with Ribbons.

Another special consideration is running add-ins on Windows Vista — at present, Access add-ins have problems with Vista security, while (at least if you have installed the hotfix mentioned in the "Running Visual Studio 2005 in Windows Vista" sidebar — Visual Studio add-ins run fine in Vista. Hopefully, v. 3 of VSTO should (at long last!) include an Access template, which should greatly simplify the process of creating Shared add-ins for Access.

airpXrir' _

reating Standalone Scripts indows Script Host

For many versions now, Windows has had its own scripting language, Windows Script Host, a dialect of Visual Basic Script (VBS). Windows Script Host (WSH) scripts can be run from the command line (for those versions of Windows that have a command line, click Start C Run), by double-clicking the script file in an Explorer window, and also from the Windows Vista Task Scheduler, which is handy if you want to run a script automatically, on a regular schedule.

One use for a WSH script is to create a database backup at regular intervals; another is to copy Word or Excel templates, or other supporting files, to the appropriate folder, as part of an Office application setup, when you don't want (or need) to create a full Install package. WSH scripts are also useful for working with files in a folder, doing tasks such as deleting or renaming files containing a certain prefix, suffix, or extension. This chapter describes how to create and modify WSH scripts, including sample scripts for some common uses.

0 0

Post a comment