DLL example to expand vb.ext

[NoDed]

Hi Kelly and thanks for providing us with this excelent programming tool.

Can you please post a dll example in how to extend the vbcorlib like you said in the vbcorlib blog ?

Thanks!

[Kelly Ethridge]

Hello,

Lets see... what did I mean when I said that?

Well, when I said extending VBCorLib itself, what I meant was to add new classes and functions to the actual library. This would happen if I felt some functionality was left out that should be put in it.

I also said adding new DLLs to the VB.EXT framework. By this I meant just that. Creating new DLLs that use and depend on VBCorLib, thus allowing the new DLLs to be easily used in tandem with VBCorLib as part of the same framework.

For instance, the next DLL to build will be the System.dll from .NET. I'll call mine VBSystem, and it will house many of the same classes and functionality. All of the classes will implement proper interfaces defined in VBCorLib and use much of the functionality in VBCorLib. The framework will simply expand and grow.

As far as an example, I'm at a loss at what to provide you. I'm not sure what kind of example you are looking for. I can't see VBCorLib itself being expanded much, other thatn what I've said in the blog (maybe multi threading). But the VB.EXT framework will continue to grow.

Did I just write a long answer that actually didn't answer anything?

Kelly

[NoDed]

Hi,

Thanks for answering to my question.

The answer is fine, my idea of extending vbcorlib was creating other dll's like vb.graphics.gdi.dll or vb.directx.directdraw.dll based on vbcorlib.dll (using classes and structures from vbcorlib) in order to extend the VB.EXT framework, I don't know where and how to start so that's why i requested an example. I will try, if something comes up I will post an example.
Thanks again.

[Kelly Ethridge]

Hello,

Ok, noooooow I'm with you. You want to extend the framework, too. And want to know how to integrate it using VBCorLib. That's great! The only real requirement is to implement the IObject interface everywhere, even if the class doesn't seem to need it. That will provide the most fundamental integration into the framework. Other than that I try to implement all the interfaces that the .NET counterpart class implements.

As for error handling, I always Throw exceptions, not just raise an error. This helps with using Catch in error handling routines. And don't be afraid to create your own exception classes. I provide several base class templates to start from.

Other than that I just constantly look up the .NET class in the MSDN to figure out the method calls. And that brings up overloaded methods. I try to simulate that as best I can. I also simulate static class methods.

Ok, I'm going to have to write something up. Something to help try and keep everything feeling the same across the framework.

Thanks for bringing this up. If you come up with something to write, could you let me know and then we can see what a good way to design it in the sense of the framework? For such things as constructors, overloaded methods and static methods. I'm sure that will help me to define a set of best practices for achieving a consistent feel.

Thanks,
Kelly