March 5, 2021
Hot Topics:

ActiveX Control Tutorial - Part 4

  • By Karl Moore
  • Send Email »
  • More Articles »

Thankfully, by the end of this tutorial you will have finished the Super Cool Text Box control we've been working on. And that's good, 'cause I'm getting bored now.

In fact, I haven't experienced this much boredom since the time London Ritz Hotel made a slight booking error and placed the entire Wool Appreciation Society in the same meeting hall as the International Morris Dancer's convention.

<Ed: Really? How did you find out about that, Karl?>

<Karl: I'm Morris Dancer number #2538>

So far in our lil' project, we've added a few funky properties, checked up on enumeration and resizing, figured out raising events and even used a wizard to help save time with any run-of-the-mill coding.

But last week, I left you on a cliffhanger. Oh yes, don't deny it.

You see, after the wizard finished running, it left a wad of 'read and write properties' code all over the place, remember? The question was, what does it all do?

Well, sit back my little cherubs, as I explain all.

<Babble mode: ON>

Let's say you go ahead and add our spicy control to a nice test project. You then alter the 'AcceptType' property to 'Letters', save everything and marinade overnight in a healthy dollop of hard disk juice.

The next morning, you return and open the project. But <shock, horror> the 'AcceptType' property is now displaying the default 'All'.

So what happened? Who stole the property?

Well, let me give you a clue: it wasn't the Butler. Oh no. The truth is we simply haven't told Visual Basic that it should save the property.

"Why doesn't VB save it automatically instead of forcing programmers to do all the hard work?" - Good question.

Let's think about it hmm, I guess some properties don't really need saving. For example, the SelText property of a Text Box, which returns any text currently selected, doesn't need saving but it is still a property.

Yet other properties such as 'AcceptType' clearly do need saving and Visual Basic does provides a neat method for doing this. OK, so how do you actually tell VB to save your property?

<Babble mode: STILL ON>

When an instance of your control is saved, the WriteProperties event of the UserControl (that's your control 'workspace') fires. In addition, a 'PropertyBag' is passed as an argument to this event.

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)

A property bag is just a virtual bag that stores, err, properties.

<Ed: No? Gee, nothing gets past you, Karl!>

In effect, it's a holding place for values. And you can read and write to this group of values by using two of the property bag methods.

So let's pretend a developer is using our Super Cool Text Box control and changes the Text property in design mode. The geezer then hits the Save button.

Quicker than you can say antidisestablishmentarianism, Visual Basic (*) yells to your control, "Hey, I'm trying to save here" and fires its WriteProperties event passing a property bag to it.

Private Sub UserControl_WriteProperties(PropBag As PropertyBag)

You can imagine this property bag as a shopping trolley without the wonky wheels your task is to fill it up with the information you need to save. You do the "filling up" like this:

Call PropBag.WriteProperty("Text", _txtTextBox.Text, "")

Here you're running the WriteProperty method of the passed property bag. You're telling it to save this information under the heading of "Text", with a value of txtTextBox.Text. The final double-quotation marks indicate a default value of, well, nothing actually.

So you write values to the property bag and hence, save your control properties, such as Text - using this template:

Call PropBag.WriteProperty(PropertyName, _PropValue, Default)

Let's take a peek at another code example:

Call PropBag.WriteProperty("ConvertCase", _m_ConvertCase, m_def_ConvertCase)

Here, our code is saying "Save this item under a heading of ConvertCase, with a value of m_ConvertCase and a default value of m_def_ConvertCase".

So in brief, the WriteProperties method fires when a control is being saved. You're passed an 'empty shopping trolley' and asked to put all the stuff you need to save into it. Typically this trolley is stored along with the thing that uses it, such as in a Form FRM file.

Take a quick look at your Super Cool Text Box project. Notice how the Wizard automatically added all this code for you? You'll get a chance at writing your own WriteProperty code later.

Anyway, that's how you tell Visual Basic to save the values of your properties, such as AcceptType.

But what about when the user opens his or her project? How do we get the property values we've just put into the property bag back out?

Top Tip: You may wonder why, in addition to passing a 'PropValue' value, we also send the WriteProperties method a 'Default' value. Erm, why bother passing across two values? Won't it simply be the 'PropValue' that gets saved not the default? That one puzzled me for a while. But it appears the WriteProperty method compares both the property value and the default and only saves if they're different. After all, it would waste disk space to save the redundant default value of a control such as the Text Box BackColour being white, when it's white by default. But by supplying this default, it allows the property bag to compare and decide which bits it should save. Clever stuff, eh? You'll understand this concept more as we delve further into default values over the next section.

* Asteriskical Top Tip (hah, and they sed I couldn't spel!): Actually, when you finally distribute your control it's not only Visual Basic developers who'll be able to utilise it. When you create an ActiveX component of any type, it's automatically compatible with all ActiveX/COM-aware programming languages, including Visual C++

Page 2 of 8

This article was originally published on November 22, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date