A reader recently asked:
Is there any way on Access 2007 to keep wizards and Switchboard Manager coding in VBA, any way developers “HAVE” to code for most applications.
If a customer is buying an apllication from us, he is not going to trust what he bought?.
Switchboard manager was great in its code handling.
Good question. Let me back-track a little into the annuals of the decision to move the button wizard from VBA to macros. There are a significant percentages of Access databases that are built by information workers that have very little code. One of the many goals for Access 2007 was to expand on this and allow IWs to build better applications without writing code. The new security model allows users to run databases without any VBA code enabled (this is important for many organizations). As you know, trusted locations make it much easier to deploy databases with code. Our wildly popular templates are functional databases that don’t have code. Feedback on the templates have been positive.
We started running into scenarios where IWs opened a database and added a switchboard or button that didn’t work. Users were confused–they didn’t work because the database wasn’t enabled. As many of you have complained about over the years, the wizards also wrote out poor examples of VBA (doMenuCmd 97 kind of stuff). To fix the problem we converted the wizards to write out embedded macros that run in untrusted databases. We also spent time cleaning up the code they generate to provide users with better learning examples.
We did consider a flag to write out either VBA or macros but the feature was one of many things we wanted to do that didn’t make it into the release. Beta 2 shipped and we got lots of feedback from beta testers (Pat Hartman and John Viescas were particularly vocal) that they wanted a way to convert embedded macros to VBA. As a late change we made it possible to convert embedded macros to VBA. You can find the command on the Database tab under Macro.
Do we think everything should be written in macros? No–they aren’t a replacement for VBA. VBA will continue to ship and be supported in the future. Macros are turning out to be useful for simple actions that took a few lines of code. We find that IWs are much more successful making small changes to macros than VBA. I have yet to hear a perf complain on macros verses VBA, so performance shouldn’t be an issue. Long-term, we intend to continue to innovate in this area and make macros more useful for broader developer scenarios.
Thanks for your question and hope this explains our logic.