"TrollKit 1.0" - Not quite "Patterns & Practice" Material
I am sure the "Patterns & Practice" team @ MS are squirming about this InteropForms Toolkit 1.0.
Honestly, I am a little disappointed in the emergence of this toolkit. Ideally MS should’ve created a migration path process and set of patterns to allow the developer to understand the inners-workings of this Frankenstein type applications. Instead MS decided to give the developer community what I would call a “TrollKit”. What happened to teaching people how to fish, instead of providing them with fishes?
Please do not use this “Trollkit”, instead take the route of visual inheritance & COM Interop, create your own set of class libraries, add WinForms to these class libraries, and you will be able to do anything with them without having to rely on this botched MS template. Did you know that if you take the visual inheritance approach, you can even have your .Net Forms use the AppName.exe.config file when launched from the VB6 executable just by having the config be the same name as the VB6 executable (AppName.exe).
To learn more about Visual Inheritance go here:
http://go.microsoft.com/fwlink/?LinkId=26900
To learn more about making these WinForm type of class libraries work in VB6 via COM interop… go here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconInteroperatingWithUnmanagedCode.asp
[2731 byte] By [
J.C.] at [2008-3-1]
Hi J.C.
Thanks for your candid feedback.
I understand your point that developers benefit from understanding patterns and inner-workings. The goal of this was to make the process and guidance simple so developers can be productive and get the job done (right). Productivity is what sets VB apart. The toolkit was built on a sound pattern in my opionion. This implementation is actually based on the patterns used in the CAB released by Patterns & Practices (albeit streamlined), and it is used in mission critical customer apps in the field.
I think we are both proposing patterns that require creating a layer over an ordinary .NET form that is COM callable. In your case you visually inherit from the .NET Form. In the toolkit case, the .NET Form is wrapped with a custom class that inherits from a custom Form base class. The benefit of this base class is that it simplifies and hardens the interface exposed to VB6 and COM. E.g. the pattern used for raising an event is less error prone; the property exposed for Caption is familiar and type safe to the VB6 consumer. Not all .NET types as you know will marshall well to COM.
I'm interested to understand if there are other specific issues or limitations you see in the current implementation. The code gen and base classes are extensibile, plus we offer source code. There might be ways to achieve the pattern you want in a derived class.
In my humble opionion, this is still a sound approach that makes it easy and a no-brainer to do partial upgrades. If this is not sound in specific ways, we will have the goal hard to correct it. I'm happy to discuss that openly here or offline.
Best,
Paul
