Microsoft & .NETVisual BasicActiveX Control Tutorial - Part 5

ActiveX Control Tutorial – Part 5 content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Ciao and welcome to the fifth and final instalment of our ActiveX control tutorial.

As ever, I’m your host Karl Moore, and if you’ve missed any of the previous slots, check them out here:

  • Part One — Introduction to ActiveX controls
  • Part Two — Properties, Enumeration, Resizing
  • Part Three — Events, Mapping, ActiveX Wizard
  • Part Four — Wizardy Whatnots Explained and Property Bags/Pages

This week, we’ll be:

  • Finding out how to distribute your control
  • Answering common questions
  • Learning techniques to ensure your creations stand out above the crowd
  • Looking at how you can use this new skill to enhance your career

So grab your poisoned-nib arrow and SAS survival handbook – and let’s finish the adventure of a lifetime. Alternatively, sit back and enjoy the tutorial.

So, you’ve finally perfected your wonderful creation. It’s flashes, whizzes and whirs – and packs more code than Bletchley Park in 1947.

Now what? Well, we need to distribute the control to our end users.

Thankfully, this part is really easy. In fact, even my pet iguana Strangely Green can do it. You may remember him from the database tutorial. Cute lil’ thing.

Am I digressing? Oh, sorry. Well, let’s get on and figure out how to distribute your control:

  • Launch Visual Basic
  • Open the control you wish to distribute, such as the Super Cool Text Box we’ve been working on over the past few weeks
  • Click on File, Make <ProjectName>.ocx

  • Select the .OCX location in the dialog box and click OK

After a little cranking of the hard disk, Visual Basic will create your own .OCX file. This is your final control.

Top Tip: An OCX is to your ActiveX control what an EXE is to a standard VB project.

So that’s our actual ‘EXE’ sorted. Before we create the setup program for our end user, let’s see our control in action:

> Create a new Standard EXE in Visual Basic

> Select Project, Components

> Find your control in the list, select it and click OK

Top Tip: If your control is called something like ‘Project1’, you can rename it by reopening your control in Visual Basic, selecting Project/Properties, entering something into the ‘Project Description’ box and then recompiling the OCX as above.

You should now find your control in the toolbox of your Standard EXE project.

> Add the control to your form

> Try playing with a few properties, methods and events

You should find that your control works just like any other. And if so, that’s excellent. Let’s continue with our setup program:

  • Launch the ‘Package and Deployment’ wizard, found on the Start menu (usually within the Visual Studio or Visual Basic Program folders)
  • Select your .VBP ActiveX control project after clicking the ‘Browse’ button
  • Hit the ‘Package’ icon
  • If asked if you want to recompile your OCX file, select ‘No’ we did that just a few minutes ago

Now it’s time for the wizard to step in. Follow the prompts through to the end. Note that:

  • On the ‘Cab Options’ screen, select ‘Multiple Cabs’ if you’re going to distribute via floppy disk, or ‘Single Cab’ if you’re going to dish out via CD-ROM or as a zipped up download from the Internet
  • On the ‘Installation Title’ screen, enter the title of your project such as ‘Super Cool Text Box’
  • If you want to save your setup settings for a later session, enter a script name on the ‘Finished!’ screen

Most of the time, you’ll be fine just accepting the defaults. But be sure to read the explanations and change anything you desire.

  • When you’ve cycled through all the wizard screens, hit Finish
  • After your machine stops buzzing, read the brief status report then click Close

That’s it! You’ve just created a setup package for your control, ready to be distributed to your end users!

Try checking out the folder in which the wizard placed your setup files. You did make a note of it, right? It’s probably called ‘Package’.

Try copying these files across to a different computer, running the Setup program (setup.exe) and trying out your control within Visual Basic, Excel or whatever. It should work just the same as it does on your computer!

Well done! You’ve just created and tested a setup package for your control!

In fact, you’d better keep those test setup disks. They’d make an ideal Christmas present for any self-respecting nerd.

Important Top Tip: Now that you’ve compiled your control, it isn’t just restricted to use within Visual Basic. You could utilise it within Excel, Word, Internet Explorer, Visual C++ or any ActiveX-aware application!

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 FilesMicrosoft Visual StudioCommonGraphics 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.

<Ed: Phew!>

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.

Raising Errors

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.

Getting it on the Net

If you have the urge, you can even get your control on the Internet. How?

Well, you might want to test it within Internet Explorer (IE) first. Whilst in your ActiveX control project, try selecting Project, Properties then clicking the ‘Debugging’ tab. Choose the ‘Start component:’ option and select your control. Then click OK and press F5 to run your control within IE.

Whilst running in the browser an ActiveX ‘container’ – click on View, Source. What do you see? Does this make sense after reading the section on class IDs?

To create an Internet setup package for your control, run the Package and Deployment wizard as earlier but this time select ‘Internet Setup’ as opposed to ‘Standard Setup’ and follow the on-screen instructions.

Adding an About Box

Ever noticed how some controls have a really cool ‘About’ box that you can activate by clicking on the ellipsis at the top of the Properties window?

Well, you can add your own by including the following code in your control:

Public Sub About()' load your about form, whatever it may befrmAbout.ShowEnd Sub

After this, select Tools, Procedure Attributes. Select ‘About’ from the drop-down list, then click on the ‘Advanced>>’ button. From the procedure ID drop-down, select the ‘AboutBox’ option. This tells the Properties window that this piece of code displays your About box.

And that’s it!

Top Tip: Don’t forget that you don’t have to display a form as your About box, it could just be as simple as a message box (MsgBox). Still, a form does look groovier!

Let’s Get Multiple

You may have already noticed, but some OCX files pack more than just one simple control. Oh yes. Take the ‘Microsoft Windows Common Controls’ that ship with Visual Basic. That includes a whopping nine separate controls.

So how can you have more than one control in each ActiveX control project? Simple. Just click Project, Add User Control. This adds another ‘workspace’ to your project, which is the ‘form’ of your control.

And then continue developing just as you would normally. When you finally compile the control and add it to a test project, you’ll notice two icons in the toolbar one for each ‘workspace’ (User Control) in your project.

Protecting your Control

So, you’ve created your own supercool control and want to release it to the world – but are slightly worried about devious developers devouring dodgy yet delectable distributions? Or in English, you’re worried about piracy?

No problems. Although I’ve never personally needed to go this far, there are numerous programs on the market to help you create ‘Trialware’, a time- or feature-limited product that gives developers a taste of your talents.

One such example is Soft Sentry 3, a trial of which is available for download from

Retrieving the Control Name

Ever wondered how the Text Box control inserts its Visual Basic name into the Text property each time you add one to a form such as Text1, Text2 and so on?

It’s easy to do. Simply grab the DisplayName property of the Ambient object, like this:

Text1.Text = Ambient.DisplayName

Don’t forget, the Ambient object contains information about your control’s environment, such as the BackColor and Font of the form it resides on. It’s a good idea to make your control be a good little boy – and use these properties to set it’s own BackColor and so on.

First off, I’d like to personally congratulate you on getting this far in the ActiveX control tutorial. It’s been a tough course, but you’re obviously a tougher cookie.

But where do you go from here? What should you do with this newfound talent?

Well, controls are a great way to encapsulate all your hard work and programming logic into a simple widget you can throw onto a form. Or an Excel spreadsheet. Or a Word document. Or whatever.

They allow you to take all the complicated stuff such as the code we wrote for the Super Cool Text Box control, the actual Text Box and so on and turn it into something simple, our end product.

Wondering where to go next? Here are a few control ideas I thought about whilst having a shower this morning:

  • Improved Timer Control The current Timer that ships with Visual Basic fires off, at the very least, once every 65535 milliseconds (just over a minute). Sometimes I want a timer to fire every ten minutes or so and end up writing code to increment a timer counter, fire off, reset the counter and start again from the beginning. It gets very sticky though all this work could be encapsulated into a control.
  • Date Picker Control – You could take Microsoft’s existing Date Picker control and add your own unique properties. For instance, IsWeekend (Boolean), FirstDayOfMonth (Date) and LastDayOfMonth (Date). If you wanted to be really groovy, I’m sure an IsPublicHoliday (Boolean) would also be greatly appreciated!
  • Marquee Control How about creating a control that scrolls text along a Text Box or Label? I guess you’d use the Timer control to activate the movement, and change the Interval depending on how fast you wanted the text to move.
  • Do That API Thang As the API section ( shows, you can do a lot of groovy stuff with API calls. For instance, you could spice up the Text Box control by adding new features ( Or include new properties in the Tree View control, such as ‘BackgroundColour’ currently only changeable via API calls.

… and the list goes on!

So go ahead and let us know how you progress! Feel free to post your achievements right here on our bulletin board.

If you’re interested in what other programmers are getting up to, you might want to check out:

  • Progress Control See how the guys at VBWeb created a progress control that throws Microsoft’s Progress Bar right out the window.
  • Chart Control Learn how our very own Sam Huggil decided the Microsoft Chart control was too big to distribute with his applications so created his own version! (I’d also like to mention that Sam has a couple of neat ActiveX control tutorials here.
  • Hyperlink Control – Once again, the chaps behind VBWeb dress to impress with this groovy Hyperlink control. (More controls from VBWeb here).
  • Visual Dice Control Check out how VBExplorer knocked up a visual die for potential use in games.

Check these out, look at the source code, learn how they work. That’s the best way to continue exploring ActiveX controls.

You may also want to check out the Component Source store, which lists dozens of commercial third-party controls.

This week, we’ve figured out how you can pack your groovy ActiveX control into a neat setup package.

We went on to tie up any loose ends and discussed how to change the toolbar control image, how class IDs work, figured out raising errors in code, took a peek at products to help with resizing and creating trial programs, looked at the Ambient object, plus even skimmed over how we can get our control online.

The tutorial then (finally) concluded with a look at what others have done with controls, plus a roundup of ideas for future practice.

Whew, I think we need a rest!

Hopefully this tutorial has helped you understand how to create your own ActiveX controls, plus given you an even greater knowledge of Visual Basic. I hope it gets you a better job, a pay rise, and possibly a small island near Hawaii. A girlfriend wouldn’t go amiss neither.

Err, just don’t forget me, OK?

But whatever you get up to, in and out of the Visual Basic realms, I’d like to wish you all the very best and thanks for joining me in our adventurous trip to ActiveX land.

So until the next time, this is Karl Moore signing off, hoping you all have a pleasant evening, wherever you are. Goodnight!

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories