Fog Creek Software
Discussion Board




Dynamically compile a TypeLib into a DLL resource

I might be on the wrong track... thought asking a non-code-pasting-forum might help:)

What I want to do:

Add (enum) constants to a ActiveX.DLL created by visual basic. I want to do this on the fly. These should then be visible in the TypeLibrary VB load when referencing the DLL.

Is there a way to do this without learning ALL of COM? I have a sore head allready...

Does anybody know: Is the format of a .TLB file the same as that of a TypeLibrary Resource? Can I "paste" it in?

Daren Thomas
Tuesday, October 08, 2002

You're asking for a world of hurt, here. :-)

What you're asking for CAN be done, but you'll effectively have to re-generate the typelib, and then fake running the resource compiler to re-bind the resource into the dll. Unless you want to leave the TLB separate, in which case you can at least skip that step.

Don't try and hack the tlb bits themselves; the format's complicated and undocumented. There's a complete set of TLB access objects that expose a COM interface and let you read and write tlb's. Of course, you'll need to do COM coding to do that.

If I may ask, what's the reason you want to do this? The languages that take advantage of enum definitions in typelibs are compiled anyway, so they won't see your on the fly definitions. What are you really trying to do? Perhaps there's another way.

Chris Tavares
Tuesday, October 08, 2002

My biggest nightmare: Error codes.

I work for a small company writing software for our companies. As most projects have lots in common, handy classes creep up everywhere. This is A Good Thing, I guess - just I can't sleep for one worry: How do I ensure, that the error codes a (Visual Basic) class throws are unique among all projects?

I tried using an Excel list. But hey, would you expect that to work? Not all my collegues are as disciplined when it comes to coding as I am. Luckily - or they would be just as boring :) No really, it just takes to long!

I have a dream: A database with error codes and corresponding error messages. Add new error codes while you write your class. Push a button - the db frontend installes an updated dll on your pc with all the error codes.

The dll will also contain usefull functionality for dealing with errors, including an ErrorObject wrapper like the one described in Hardcore Visual Basic.

Basically, I want to solve a problem I face every single time I start to code!

What do you meen with "fake running the resource compiler to re-bind the resource into the dll"? Using the TLB access objects you mentioned before should produce a "compiled resource" and binding the resource into the dll, as far as I could figure out can be done with UpdateResource - or a linker.

I feal I am missing quite a lot here! Can anyone recommend a good book for learning COM? I guess sooner or later I will have to!

Daren Thomas
Wednesday, October 09, 2002

FIXME: we write software for our companies clients.

Daren Thomas
Wednesday, October 09, 2002

Don Box, "Essential COM" is the usual citation.

As for project managing stuff like error numbering, helpids and all the other application related junk you get into when you produce many appplications,  I keep looking for something myself that will manage everything and then I think, well I could do it myself and I make some small hamfisted attempt and then lose the will to maintain it.

Hmmm, maybe I should just write it properly anyhow.

Simon P. Lucy
Wednesday, October 09, 2002

Youre there already. Not that I tried this.

Make / Generate an IDL with all the whatever you want.
Compile the idl to a tlb
"UpdateResource" the TLB into the DLL.
Distribute the DLL.

Maybe I'm missing something?

Pundit Du Jour
Wednesday, October 09, 2002

Ok, I see the problem.

Yes, the tlb is exactly the same as the TYPELIB resource.
Virtual excerpt from actual rc file -

MyApp.rc
3 TEXTINCLUDE DISCARDABLE
BEGIN
    "1 TYPELIB ""MyApp.tlb""\r\n"
END

Pundit Du Jour
Wednesday, October 09, 2002

'I work for a small company writing software for our companies. As most projects have lots in common, handy classes creep up everywhere. This is A Good Thing, I guess - just I can't sleep for one worry: How do I ensure, that the error codes a (Visual Basic) class throws are unique among all projects?'

Is it really necessary for different classes to have different error codes?

Jason McCullough
Wednesday, October 09, 2002

"Is it really necessary for different classes to have different error codes?"

No, not really. But it IS handy. This has to do with the way error handling works in Visual Basic: You can either check Err.Number in an error handler (a label to GoTo) or after each call (I think this is the structured error handling approach used also in C?).

I prefer the first, because more often than not, I expect my code to work. When an error does happen, I can then test Err.Number to find out what went wrong... but if Err.Number is not guarantied to be unique I start to get paranoid.

Daren Thomas
Thursday, October 10, 2002

Great! I can now UpdateResource a TLB! In fact, that IS part of the information I needed. Thanx!

The singing and dancing version would of cource compile its own TLB...

Does anyone know where I can find documentation (or at least the containing library) of the TypeLib Access Objects mentioned earlier on?

Thank you for your help.

Daren Thomas
Thursday, October 10, 2002

Here's a good place to start:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap9_4dwv.asp

Poke around in that section of MSDN - all the docs are there.

Chris Tavares
Thursday, October 10, 2002

*  Recent Topics

*  Fog Creek Home