How to: Move an application to release 2.0

Move an Access application that uses the WKL controls from release 1.x to release 2.0 of the WKL Forms Object Library. Release 2.0 renames the type library. Every application that names it in VBA or in its references has to be changed once.

Prerequisites: You need the source of the application: an ACCDB or a project built with the build tool or the WKL Office SDK. An ACCDE can't be changed; build it again from its ACCDB.

The library ID, the class IDs and the members of the controls are those of release 1.68. Forms and reports keep their WKL controls with all settings. Only code and references that name the library change.

Only one of the two releases can be registered for a Windows user. Registering 2.0 removes the registration of 1.x, including the WklComponents.* ProgIDs; registering a 1.x release again replaces 2.0. Move every application a user works with at the same time.

1. Register release 2.0 on the development PC (How to: Install the released package). From then on, the ProgIDs WklComponents.* aren't registered on this PC: CreateObject("WklComponents.Texts") and similar calls fail with run-time error 429.
2. Open the database without its startup code. Hold down Shift while you open it, so that the startup form and the AutoExec macro don't run against the old references.
3. Check the reference. In the VBA editor, choose Tools › References. When the database opens, Access binds its reference to the registered release 2.0 through the library ID. If WKL Forms 1.x Object Library is still marked as MISSING, clear it and select WKL Forms 2.0 Object Library.
4. Replace the library name in the code. Choose Edit › Replace, search for WklComponents, replace it with WklForms, and choose Current Project as the scope. This covers declarations such as Dim tree As WklComponents.WklTreeView, ProgIDs in CreateObject("WklComponents.Texts") and comparisons with Err.Source.
5. Look for the name outside the modules. Text that isn't VBA code, for example a ProgID in a table, a query or a macro, isn't covered by step 4. Search the objects of the database for WklComponents and change them the same way.
6. Compile. Choose Debug › Compile, fix any remaining lines, and save. Then make a new ACCDE from the ACCDB.

For a project built with tools\build\Build-AccessApp.ps1 or the WKL Office SDK, make the changes in the source files instead of the database:

• In references of access-app.json, change { "library": "WklComponents", "major": 1, "minor": ... } to { "library": "WklForms", "major": 2, "minor": 0 } (access-app.json). The build stops with a message as long as a reference names WklComponents.
• In source\references.json of a WKL Office SDK project, set "name" of the reference with the library ID {A37D549E-FCD0-48EC-8B14-C7323B747E4F} to WklForms, "major" to 2 and "minor" to 0.
• In the exported modules, forms and reports, replace WklComponents with WklForms.
• Build again. The new app-manifest.json names WklForms with version 2.0 under requires (app-manifest.json).

The application compiles against WKL Forms 2.0 Object Library, and its forms show the WKL controls as before. Deliver it to user PCs only together with release 2.0 (How to: Deploy an application with WKL controls to user PCs), and with WKL Bootstrapper 3.1 or later: only from 3.1 on does the starter recognize applications for 2.0 and register Wkl.Forms.ObjectLibrary.dll; earlier versions know only release 1.x. An application that hasn't been moved yet can partly keep working on a PC with release 2.0, because Access binds its reference through the same library ID. Anything that uses the ProgIDs WklComponents.* or compares Err.Source with WklComponents fails there, though. Operation is supported only with the major version the application was built against.