Mr. Cluey : How To ...? : Wrapping OCX Methods

How do I create a seemless wrapper for an OCX Method?

While working on writing a class declaration for a custom control, I ran smack into a problem that looked to be disasterous.

My scripts were littered with calls that looked like this

anytype aFoo = MyApp.MyOCX1.FooBar () ;

only to discover that FooBar(), under certain circumstances, returns NULL - and QAP throws an exception ( E_PROPERTY_TYPE_MISMATCH ). It's easy enough to code around the problem - using a do - except loop. The new code might look like this

winclass CMyOCX : AnyWin
{
	ole ANYTYPE FooBar () ;

	ANYTYPE NewFooBar ()
	{
		anytype aTemp ;
		
		do
			aTemp = this.FooBar () ;
		except
		{
			ConfirmException( E_PROPERTY_TYPE_MISMATCH ) ;
			aTemp = Null ;
		}
	}
}

This isn't particularly satisfactory for a few reasons.

• You are warping your scripts to hack around a QAP issue. Patches like this one should be seemless.
• You now have to hunt through all of your scripts, changing all of the calls from FooBar to NewFooBar.
• There is no way to prevent new scripts from being written using FooBar()

Solving the Problem with Aliasing

All of these problems boil down to one single point - NewFooBar is artificial, a convenience to deal with a problem, but it doesn't reflect the actual intent of the code. Put simply, we don't want to call NewFooBar - we want to call FooBar.

Thanks to aliasing, we can.

Aliasing isn't given a lot of coverage in Segue's documentation.

Visual Basic 4.0 and OCX Support Reference

Page 11 shows examples where the alias keyword is used with OCX properties.

QA Partner and QA Organizer User's Guide

Page 388 gives details about aliasing a dll function.

This is the solution to our problem. What we are going to do is set up an alias for the ole function - which effectively hides that function from your scripts. Then we create a method with the name of the unaliased OCX method, put the aliased method inside it, and add our error checking. It sounds more confusing than it actually is.

winclass CMyOCX : AnyWin
{
	ole ANYTYPE AliasedFooBar () alias "FooBar" ;

	ANYTYPE FooBar ()
	{
		anytype aTemp ;
		
		do
			aTemp = this.AliasedFooBar () ;
		except
		{
			ConfirmException( E_PROPERTY_TYPE_MISMATCH ) ;
			aTemp = Null ;
		}
	}
}

It doesn't look that much different from what we had before, but it is much cleaner. Your scripts now call FooBar(), without worrying about whether that is a wrapper function or the original. The change is completely seemless - nobody else needs to know it is there. Don't forget to double check that both function prototypes are the same.

Note the syntax of the alias. Properties get prepended with a dollar sign ($) but methods do not. I was surprised that the quotes are necessary - the example in the User's Guide suggests that they are not, but my code doesn't compile without them.

Don't fool yourself into thinking that you can leave the code like this. This block, and other's like it, requires a carefully written comment to explain both WHY this is necessary and how it works. Even if you remember, it may not be you that goes back into this file when the next problem occurs.