ActiveX or Vanilla DLL - Can multiple objects dynamically support the same Interface and be swapped out at run-time?

I am working on an MFC app.

I have created several classes with the same name and public methods, though each implement those methods quite differently.  For example, lets say that they all have the same method that takes a string input, though each class searches for a different regular expression on that string and returns true or false based on its findings.

I want to be able to load a single instance of one of these objects into my MFC app during run-time, to which the user can pass strings to.

 I also want to be able to unload the current instance of this object and reload an instance of one of the other class objects at run-time to allow for the user to search using another regular expression.  This way, the application only has to know about the single interface that each class supports and the existence of the dll's or controls from which it can select to load.

I am not sure if I am barking up the wrong tree, or if the simplified example above can be implemented using ActiveX controls or just plain dll's or not.

I want to be able to easily give the user a new Control or dll in the future that will add further functionality.

Will the AtiveX or COM techology work for me in this regard?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AndyAinscowFreelance programmer / ConsultantCommented:
From a plain dll you can't export a class.  You can export functions but with different names.  Different dll's can export functions with the same name.

So you could have one dll and export Fn1, Fn2, Fn3... to manipulate the string differently.
Or you could have multiple dlls and LoadLibrary(Dll1, Dll2, Dll3...) followed by calling the function of the same name in each.

An alternative you haven't specified is one dll, one function BUT passing multiple arguments.
bool Fn1(LPSTR pszText, int iUseThisFunctionality) where this function in the dll has a switch to passs it onto the desired class for further processing.  [Future version just need more case statements in the switch]
>You can export functions but with different names.
I have to disagree.

This is true when you circumvent name mangling using extern "C" or a .def file.
However, using plain vanilla __declspec(dllexport) allows you to export multiple functions with the same name - so long as they are true overloads of each other (different parameters etc.). That's why C++ mangles its function names.
Granted, it does make GetProcAddress calls messy, as the mangled names have to be known. But it is possible.

>Will the AtiveX or COM techology work for me in this regard?
Yes, but be careful, because ...

>each implement those methods quite differently
Within COM, the function (and interface) semantics have to be exact and immutable.
It is suited - I not saying it isn't - just word your semantics properly.

Final note. This really sounds like a textbook case for COM monikers.

as far as I understood your question, this is exactly one of the targets of COM.
Both things are possible, two or more classes can implement the same interface, or two or more classes can implement different interfaces with equal names.
The first case is not so obvious because the VC Wizard does not provide that (at least upto VC6.0 doesn't) but COM is not limited to that what wizards can do.

Imagine e.g. the Value property of an Office application this applies to more than a dozen of components
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

AndyAinscowFreelance programmer / ConsultantCommented:
Hi _YS_
>You can export functions but with different names.
I have to disagree.

Yes, you are correct re differing parameters.  However the question was about having the same input parameters (string, or so it seemed to say).  Hence the export would not work as I understand it as the function name, return and calling parameters would be the same.

I realise your point was made within the context of the question.

My intentions were to make Skytzo aware that it is possible, as he does not sound as experienced as some, and may take your comment out of the context of the question.

>I have to disagree.
This could have been worded better, so as not to 'critisise'. Apologies.
AndyAinscowFreelance programmer / ConsultantCommented:
no offence taken, it was a valid criticism.  You were correct in that I made a sweeping statement rather than qualifying to the questioners point specifically.

Thanks for the apologies.
SkytzoAuthor Commented:
I have upped the points for more help.

Thanks for the comments so far.   I will look skip a few chapters ahead and read about Monikers.

To clarify some misunderstanding, here is better explanation of what my application will do.

In short, My application will read a stream of data coming in from an outside source though through a single interface, for example, through a single tcp connection.  There can be multiple sources on the outside that the user can select from which then allows the user to have the ability to change which source he is receiving from dynamically while the app is running.  Based on the source of the stream, the data needs to be passed to an ActiveX control or somethng similair that can interpret the data correctly.  I also want to easily be able to support the adaption of future streams or different comibinations of streams.  

I am wondering now if I need to have the interpretation of all of the streams inside a single COM object, or if I can still split the interpretation of each kind of stream to a different Object and allow the application to support streams that it has never seen before or that were not shipped with it when released?

Does that make more sense?  I have coded a fair amount in MFC prior to this, though never with COM.
>I also want to easily be able to support the adaption of future streams or different comibinations of streams.

As I said, textbook example for COM monikers.

>I will look skip a few chapters ahead and read about Monikers.
Happy reading.
I must point out, though not to deter you, monikers are the least used, and least understood of all the COM mechanisms out there. Take is slow. Skipping a few chapters will confuse you, no doubt about it. Better to read the background as well.

Any questions just ask.
If you're hungry for source code to see how monikers really work [or a glutton for punishment], take a look at this:

It does required a basic grounding in COM before reading.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
SkytzoAuthor Commented:
Here is another question.  Are Monikers supported from Win95.x through XP ?  Or only from NT onwards?
Moniker support has been there since the incarnation of OLE1 itself. Back in the days of NT 3.1.

Win 9x supports it as well - going back to Win95 of course (verisons a & b).
SkytzoAuthor Commented:
Thanks for the comments.

I have found a simpler solution to my problem that avoids having to touch the registry.  I will use Comm in future products though.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.