ActiveX Control Tutorial - Part 5
Before we get into the intricacies of control versioning and class IDs, let's talk about something much more important: how to replace that boring little toolbox picture that represents your control.
Open your control in Visual Basic and select the 'UserControl' object from the Properties window. This displays all the properties of your control. Find the ToolboxBitmap property and use the ellipsis to set an appropriate picture file.
The size of the toolbar bitmaps is about 16 x 15 pixels but don't worry if you're slightly out, Visual Basic will automatically resize the image for you.
If you're getting desperate for images, you might want to check out the samples that ship with Visual Basic usually in the Program Files\Microsoft Visual Studio\Common\Graphics folder.
Compiling your Control
Every time you compile your OCX control, Visual Basic assigns it a unique class ID. For example, my control was assigned the ID "DF2785AB-AA42-4EEB-9C4B-566B3B70E340".
Let's say your friend, erm, Mr Wibbleshaw, has decided to use your control in his latest program. When he distributes his creation, the setup package naturally bundles your control too.
Now here's something you need to understand: when one of Mr Wibbleshaw's forms needs to display your control, it shouts out, "Hey, I'm looking for control DF2785AB-AA42-4EEB-9C4B-566B3B70E340" and hopefully the control comes running along and plonks itself on Wibbelshaw's form.
So in other words, his application references your control by that automatically generated and guaranteed unique class ID.
And that makes sense. After all, if your control was called 'Nice Text Box' and someone else wrote a 'Nice Text Box' too the incorrect control could accidentally be displayed. And that control probably wouldn't support the same properties and methods as the first proper one.
So basically, programs use class IDs to point to (or 'reference') controls. But what if news hits the town that you've created a new and improved version of your control? All your users rush and install it, including the chaps that use Mr Wibbleshaw's program.
What will happen?
Well, every time you compile your control, Visual Basic creates a new class ID for it. That means Mr Wibbleshaw's program would probably be best using the new and improved control but is still looking for the old ID. And since you recompiled the control, it has a new ID.
Confused? Yeah, me too. But the point of this wonderfully written story is that each time you compile your control, it really must stick with the same ID. If it doesn't, it means the developer using your control has to recompile his program with your new control so it remembers the new class ID.
You can keep your ID the same by clicking on Project, Properties in your project after creating your final ready-for-distribution OCX. Click on the 'Component' tab and in the Version Compatibility frame, select 'Binary Compatibility' and choose your freshly compiled OCX file.
Now, everytime your project tries to compile, it will use the same class ID as the OCX file you just pointed to.
It's worth noting that sometimes you can't maintain compatibility between versions of your control because you've made such major changes still, if you've set the above Binary Compatibility, Visual Basic will at least warn you first.
Ever been in the middle of testing your application, when one of those horrid grey 'Error' boxes appears, offering you the option of Debugging or Ending your program? Oh, choices, choices.
Well, it's time to get revenge. You can raise your very own errors within controls by using Err.Raise()
Let's say you created some database control with a 'Username' property. And you didn't want your user to choose the name 'sa'. Let's look at how we could handle this in code:
Public Property Let Username(New Username As String) If NewUsername = "sa" Then Err.Raise vbObjectError + 101, "Username Property", _ "Cannot specify username 'sa'"Else mstrUsername = NewUsernameEnd If End Property
This raises an error in the application attempting to set your control's Username property. Groovy? I think so.
Top Tip: To find out more about raising errors within your control, look up the 'Raise Method' (Visual Basic Reference) in the Visual Basic help files.
If something goes wrong in your own code that you can't handle, you could try 'passing back' the error to the developer using your control. Once again, you could simply use Err.Raise() this time, in your error handler. You'd be raising an error that you received or rather, passing it back.
Resizing your Controls
In our sample Text Box control, we didn't have to worry about resizing too much. We simply set the dimensions of our Text Box to the dimensions of the UserControl object.
However if we were dealing with more complex items such as a File Open dialog box that needed to perfectly resize all the controls within it you'd need to get much more technical. You'd be dividing heights by three, multiplying the square root of 18 by the width of your control, then taking away the number you last thought of... and so on.
Trust me, resizing work can get pretty complicated. So you might want to think about purchasing one of the many resize controls available that simply does it all for you try checking out our ReSize OCX review for size.
Page 3 of 6