Special Requirements for Addin Code

■ When you run an add-in, the code is running from another database (the add-in library database), and you need to take this into account when referencing database objects in your code. If you want to use an object in the library database, use CodeDb to set a reference to that database; if you want to reference an object in the calling database, use CurrentDb (both CodeDb and CurrentDb are used in the Extras 2007 add-in code).

■ Only functions can be run from the Registry; all the procedures referenced in the USysRegInfo table must be functions, even a procedure that would normally be a Sub (because it doesn't return a value). However, other procedures used in the add-in library database (the ones that are not run directly from the Registry, and are not referenced in the USysRegInto table) can be subs.

■ An add-in can display forms, usually as unbound dialogs. Typically, all add-ins except menu add-ins use one or more forms (and menu add-ins can use forms too). The Extras 2007 add-in has a setup form where users can enter information that will be used by various procedures in the add-in.

■ You can reference tables in the add-in library database using the CodeDb syntax, which lets you store add-in data in tables if needed. This is useful when you want to store information that will be used for all databases running the add-in, for example the lists of table and query prefixes for excluding tables and queries from listing, in the Extras 2007 add-in.

■ Replace macros and queries with code run from public functions, so they can be run directly from the library's module(s).

■ Bound forms run from an add-in have as their record source tables in the code database, not the calling database. If the form needs to display data from the calling database, it must be copied to a table in the code database after being filled with data from the calling database, as I do in the Extras 2007 add-in for backup options, and table and query fields.

■ The DDL CreateTable statement creates a table in the current database; if you need to create a table in the code database, you have to use the more complex TableDef method in DAO, specifying CodeDb as the database in which to create the table.

■ An add-in intended to work in both Access 2007 and earlier versions of Access may need to process both .mdb and .accdb extensions, or deal with the new Attachment data type.

■ When the CopyObject method is run from an add-in, the code looks for the source object (the SourceObjectName argument) first in the library database, and then in the current database. This may require you to create a copy of a table, say with "Blank" at the end of its name, in order to copy a fresh, blank table to the calling database, overwriting a filled table, as I do in the Extras 2007 add-in code. Otherwise, you will end up copying the filled table from the calling database back to itself.

■ When run from a library database, the RunSQL method of the DoCmd object works on tables in the calling database, and the OpenQuery method works on tables in the code database.

0 0

Post a comment