Dynamic UDT TypeLibs

[Elroy]

I'd like to make a post that outlines the different options we now have for getting UDTs into Variants:

• Use the above UdtsToVariants.cls and make a dynamic (runtime) TypeLib, and then use it in the same project. Upside: Easy to use/understand by VB6 programmers. Downside: You must separately create Variant UDTs and standard UDT variables, possibly copying data between them with the methods in UdtsToVariants.cls.
  
  
• Use the above UdtsToVariants.cls, and then save the TLB file, and then register and reference that in another project. Upside: Easy to use/understand by VB6 programmers. Downside: You must futz with a TLB file during development.
  
  
• Just turn your project into an ActiveX.exe with a creatable class, and put your UDTs in this creatable class as Public UDTs. Upside: Fairly easy to use/understand by VB6 programmers. Downside: Your final executable is far from portable, requiring admin rights on first execution so it can register itself, and also possible registry clutter.
  
  
• Create an ActiveX.dll that's used with your project which has a creatable class with your UDTs in it as Public UDTs. Upside: Fairly easy to use/understand by VB6 programmers. Downside: This ActiveX.dll must be distributed with your executable and registered (or setup with SxS, or dynamically loaded).
  
  
• Write an IDL for your UDTs, and then assemble it into a TLB file with MIDL or MKTYPLIB, and then register and reference that in your project. Upside: This was the way things were originally intended to be done. Downsides: Requires knowledge of how to write C-like IDL files, requires knowledge of how to execute either MIDL or MKTYPLIB, and also requires futzing with a TLB file during development.
  
  
• Create a project with your UDTs, and then compile it as an ActiveX.exe, telling it to create "Remote Server Files" which will cause it to create a TLB file when it's compiled. Upside: Easy to create TLB file with VB6. Downside: Creating a TLB file this way will cause it to need to be distributed (and registered) with your final project's executable. And this approach can also cause possible registry clutter.

When someone asks about this in the future, I'll probably reference this post.

------------------------------------

ADDED: And yes, as VanGough pointed out (and suggested in posts above), if you keep your TLB file with your project's source, and reference it their, you don't absolutely have to register it to use it. In my main project, I tend to keep my TLB files in a sub-folder of my main source code folder. (There are actually many sub-folders there for a variety of purposes.) But again, that last option (creating TLB files with the "Remote Server Files" option), is possibly the worst option in the list because of the various dependencies it wraps into the TLB file.