You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Today’s guest blogger is Joel Graff, Operations Field Engineer with the Illinois Department of Transportation.
Many of the Access projects I’ve developed have used VBA extensively, and the more I became involved in developing user interfaces, the more I saw a need to customize the behavior of the controls that Access provides. Developing this sort of solution gave me the architecture to be able to develop much more complicated control interactions and aesthetics without getting lost in a mess of spaghetti code, ambiguous function references, and endless form/control qualifications.
A demo database is available here, so if you’re interested, download a copy and read on!
Here’s how the demo database works:
Rather than trapping a control’s event in a form module, I created a class module (referred to as a “control event handler”) which has all the event-handling stubs contained within. Of course, the main member of this class is a local WithEvents reference to the form’s control.
Once the event is triggered in the control event handler, the handler then uses the Application.Run method to execute a callback function stored in a separate module. The name of that function is passed to the event handler on initialization and can change at any time in the course of the program. The control event handler passes to the callback the reference to the control itself, an enumeration indicating the control’s type (in lieu of the ControlType property, which not all controls support), and a string describing the event which was triggered. After that is a series of optional parameters containing anything that is passed back from the original event call (e.g., MouseMove has Button, Shift, X, and Y for parameters).
So why do it this way? In most cases, you probably won’t want to. But here’s why I like it:
Some of the drawbacks include:
The demo database gives a fair idea of how it works, but you need to explore the code to really understand it. I have tried to comment it as thoroughly as possible. Note the relative simplicity of defining an event handler and callback in the Startup module. Also note the sparseness of code in the Form module. In fact, the Form module could be completely empty in many cases. However, you must have, at very least, an empty module for this to work.
The demo demonstrates changing a control’s callbacks on-the-fly, using a global callback, managing events at both the form and the control event handler class level, and managing all events through one common call-back function.
Really like the power tips! Thanks!
This is as close to a "portable control" you can get in Access. While .Net has had the ability to copy controls from one form to another for years, (control and code both get copied), no such ability exists in Access, you can copy controls but not the control and code together. Great article!
I took a little time and rebuilt the classes I wrote that implement this event handler for dynamic callbacks. They're fairly simple to use and the example database includes documentation with tutorials on how to use, modify, and create your own custom event handlers as well as create custom callbacks. The demo uses the "web button" control (featured in the article sample db). Enjoy! cid-3c2957c7b23962f1.office.live.com/.../Access%20Blog