This demo is in response to a recent thread on creating "custom controls" https://www.access-programmers.co.uk/forums/threads/is-it-possible-to-create-custom-controls.320996/ Unlike other development environments access does not have a way to make a user defined or custom control. However, but...
This is great stuff! Thanks to MajP for opening my eyes to a new dimension.
Now I have a few questions:
This class module defines the functions of the controls. So before I use this class module I need to manually places all of the controls into the form, format them to my liking, and name them to match those initialized in the code, before I run this code, right?
In addition to defining the functions, I can also refine the code to include formatting properties of the controls such as color, effect, font, or even location (in this case, where in the form to place those navigation buttons). Then all I'd have to do during form design is throw in the required controls anywhere in the form, and when the code initializes them, they will know where to go and how they should look. Am I right?
If I initialize a group of controls in a form to a single custom control class, then I have something like a control array?
I'm sorry if they sound silly, but I'm really new to this.
This class module defines the functions of the controls. So before I use this class module I need to manually places all of the controls into the form, format them to my liking, and name them to match those initialized in the code, before I run this code, right?
In the first example you do need to add and format your controls on each form. In the subform example you do it once. You can name your controls whatever you want. If you look at the two examples the controls have different names. You pass in your four controls by reference not by a name.
In addition to defining the functions, I can also refine the code to include formatting properties of the controls such as color, effect, font, or even location (in this case, where in the form to place those navigation buttons). Then all I'd have to do during form design is throw in the required controls anywhere in the form, and when the code initializes them, they will know where to go and how they should look. Am I right?
You could, but now you are kind of defeating the purpose of having generic code. So now all instantiations would always get that look and feel you would not have a way to customize. If I was going to do that I would probably have properties as well to be configurable. So I could have a location property that puts the navigation control in upper right or lower left. A font property that would be the font for all buttons and the textbox, a back color. In truth I think it would be simpler to format the buttons once and past as necessary.
However there are some classes that I build, that most definitely do all the formatting. Especially if the sizing and moving is tedious and time consuming.
This timeline example is a basically a custom class (using the subform Idea) and creates it by moving, showing, and sizing many controls.
If I initialize a group of controls in a form to a single custom control class, then I have something like a control array?
Kind of, but not really. In this navigation button example I would say no. It is almost the opposite. In a control array each item of the array is indexed and its event is handled by a common event procedure. It is a lot of controls doing one event. More like an option group where each option does one thing, return a value. With this navigation buttons it is as if a single navigation control causes multiple events (move first, move previous, ...)
However, you could build a custom class that would more closely mimic a control array.
However, in Access the easiest way to mimic a control array is with a common function serving as an event handler. See long discussion here.
There is often a lot of confusion about Access Events and often answering questions posed here is difficult because of inaccurate terminology. People often say "Event" when it is unclear if they mean the actual event that takes place, the event procedure, or the event property. This thread...
There is often a lot of confusion about Access Events and often answering questions posed here is difficult because of inaccurate terminology. People often say "Event" when it is unclear if they mean the actual event that takes place, the event procedure, or the event property. This thread...
Thank you so much for your examples. Now I think I have my two-fold approach to this problem: a template form that defines their looks (for copy & paste) and class modules/common procedures for their behaviors.
I wonder if I could also do the same with forms, like a form class modules or something, to create common forms of different functions. But I'll worry about that later.
Actually I was thinking of something like a custom message box or input box that has both a template and a class module, the contents of which will vary depending on what the code tells it to do. I'll just stick to controls for now.
Time to continue reading that Access Events thread...
This shows many different ways of getting users' attention including customised message boxes, flashing/scrolling/balloon tooltip text, form animation, transparency and fade, dim/blur/remove background
This shows many different ways of getting users' attention including customised message boxes, flashing/scrolling/balloon tooltip text, form animation, transparency and fade, dim/blur/remove background
We meet on the 3rd Friday of the month, from 9:00 am – 10:00 am ET Presentor: Colin Riddington (isladogs) Topic: Controlling the Application Interface Controlling the Application Interface presented by Colin Riddington, Mendip Data Systems. This session will show how the Access application...
