Skytzo
asked on
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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
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.
>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.
AndyAinscow,
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.
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.
_ys_
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.
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.
ASKER
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.
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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).
Win 9x supports it as well - going back to Win95 of course (verisons a & b).
ASKER
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.
See
http://www.codeproject.com/dll/plug-in.asp?target=dll%7Cloader
I have found a simpler solution to my problem that avoids having to touch the registry. I will use Comm in future products though.
See
http://www.codeproject.com/dll/plug-in.asp?target=dll%7Cloader
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]