Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Writing Extensible programs with COM and VB 1

Status
Not open for further replies.

BBirkett

Programmer
Feb 7, 2002
103
0
0
AU
I know .NET is replacing COM, but I am still interested in learning more about writing COM applications while learning the .NET framework.

I am quite experienced at creating smaller applications with VB, C, and Java, and I am compentent with creating classes and know a lot about OO principals.

I would like to take the next step with my programs, and learn how to make them extremely extensible using COM interfaces. ie..

I want to write a program that supports feature A B & C.
Then in the future, an unknown feature D is required. If I can learn how to write the program to be extensible, then D should just be a new object that gets registered, and the rest of the program can use it as if it was always there.

Does anybody know of any information or sites that can help me take the next step in application design and programming with VB?

Really appreciate any help. Brett Birkett B.Comp
Systems Analyst
 
1. Publish an interface class that your plug-ins will implement. This is done by creating a public class in a DLL that other projects can set a reference to.

2. Your plug-ins would then use the Implements keyword, and fill in the code needed to implement their functionality (like a spell checker in one plug-in, and a grammar checker in another plug-in).

3. In your initial call to the plug-in, you'll probably want to pass a reference to something in your program for it to act on, such as an edit window.

3. In order for your program to call the plug-in, it needs to know the ProgID of the plug-in. This is because it will be doing something like:
Code:
Dim objIC as InterfaceClass
Set objIC = CreateObject(sMyPlugInProgID)
If Not objIC.SomeMethodInMyPlugIn(objTextWindow) Then
   ' TODO :: Handle Error
End If
Set objIC = Nothing

Hope this gets you started.
Chip H.

 
That Number 3 point is the only part that I don't know how to do.... How do you determine what the ProgId is when the object doesn't exist yet?

ie... You write the main program that supports plugins... the main program would be the one that does the CreateObject(sMyPlugInProgId)... but how do you write this line, and support future plugins. ie how do you determine the progid of these plugins?


Thanks for your help, Brett Birkett B.Comp
Systems Analyst
 
Hey everyone...

I found a good example that solves some issues:



The whole thing is with Visual C++ examples, so if anybody can get me started with some VB examples that would be great.

Thanks. Brett Birkett B.Comp
Systems Analyst
 
The ProgID is the COM name of your project & "." & the name of your class.

So if your project is named "DBMega2K", and your class is named "SQLServer2k", the ProgID will be "DBMega2K.SQLServer2k". Beware of a 39-character limit on the length of a ProgID.

You're right, in that at some point you've got to know the name of the ProgID. You can enforce a rule that the root name of the .EXE file must match the name of the COM project name, and that the class must be named a certain name. This will allow you to dynamically load modules by simply doing a listing of your plug-ins directory. Or you could store it in an INI file, or the registry, or a flat-file, or any number of other schemes.

If you've done any object-oriented design work, having pluggable modules is very similar to the "Adapter" pattern.

Chip H.
 
Thanks for your responses chiph.

You might be interested to know that VB.Net solves the problems of having to register the progId's in the registery, or inis or flat files etc. Since .Net assemblies are complete self describing entities, there is no more need to use the registery or any other means to implement plugins!

There is a System.Reflection namespace in .Net land that gives a lot of usefull functionality that makes plugin type modules much easier to write and much cleaner!

Technically through my research, I have found it would be possible to have the person copy a dll file into a plugins directory while they are RUNNING THE PROGRAM... and have the program start using the new functionality WITHOUT RESTARTING THE PROGRAM!! Well I got excited about it anyway!!!

If anybody would like more info on this topic just let me know!
Brett Birkett B.Comp
Systems Analyst
 
Brett -

That's one of the things in .NET that I want to investigate as soon as I get the time. Right now, work is killing me (10-hour days, 6-day weeks, yuck!).

The fact that you can copy an assembly into a directory and have the program pick it up without a restart is very cool.

Chip H.
 
Does anyone have any example code that they can post here? I am looking to do the same thing but not sure where or how to start. Please help!

Thanks!
 
I've found this thread. I'm looking to do the same thing too. I'd like to get some more info on this topic, but I don't know how to get in touch with you BBirkett. Your help will be priceless for me right now.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top