Re: design and approach question

Greetings.

I'm wondering how this can be handled, and in particular if it is an
ok approach, how to do it with say, Microsoft Visual c++ 6.0 or later.
It's basically about wrapping ocx access in a dll.

Say I write an app that allows the user to manipulate data files.

Then supposed I'd like the user to be able to purchase whatever (out
of a given set {"A","C"} ) ole control they want to to use with my
application.

So say Vendor "C" offers an expensive ole control that allows
manipulating a wide variety of type "V" data formats.
Say Vendor "S" offiers an inexpensive one that manipulates many type
"R" formats.
Finally Say Vendor "A" offers an expensive ole control that allows
manipulating of type "O" formats.

What I want to do is purchase runtimes to sell of Vendor "S" and sell
my project with type "R" manipulating capabilities.

I'd like to tell my users/customers that if they want type "O"
formats, to just purchase the ole control from Vendor "A" or for type
"V" datas, the ole control from Vendor "C", and after updating a
configuration in my application and installing the ole controls, my
application would be able to make use of these.
So when I build my product, it would not contain any code belonging to
the vendor "A" or "C" (so I don't have to mess around with
royalties/contractual obligations etc).

Since I'd like the interface of the data manipulation component to be
the same for my entire application, I was thinking that I could wrap
access to the various OLE controls in a dll, and at runtime call the
correct one.

- is this a reasonable approach
- whatother approaches are possible
- does this avoid having any Vendor "C" or "A" files in my builds then
(I'm wondering if type libraries and other 'things' that get installed
when I use an ole control in a product I'm building and testing
actually belong to the vendor and also get put into what I sell).

A bit unsure of myself here.

thanks