Wednesday, July 23, 2008

Tiburón Sneak Peek: COM

I have a few minutes here so I want to write a bit about the major overhaul that went on with the Delphi and C++Builder COM feature. On the surface it might not look like much, but we really did overhaul the entire feature laying some much needed ground work for the future.



Here's a screen capture of the project manager after creating an ActiveX Library:







Notice the file with the .ridl extension in the project manager. This is a new file we have introduced in the next version of Delphi and C++Builder called Restricted Interface Definition Language (RIDL). The .ridl file is now the storage file for your type library instead of a binary .tlb file. A new tool has been built called gentlb.exe (similar to midl.exe) that compiles .ridl files into .tlb files. It is part of the toolchain so you can build from the IDE or the command line. Of course from the IDE you get the code updaters for when you add new methods and the stubs are generated for you. But you can also do all that by hand if you desire. We now treat the .tlb file as any other intermediate file like a .obj or .dcu, so eventually it'll be safe to add it to your clean list. Make sure you back up the original .tlb first. From now on you can diff and merge changes to the .ridl file as you would any other text file. This should really enable more than one developer to work on a COM project.



Here is a screen capture of the new type library editor:







Notice there are tabs at the bottom similar to what you see with the form designer. From left to right Code, Design and History.

Yeah, we have a history view just like any other text file in the IDE:







And of course you can look at the .ridl file like any other text file. Here is a screen capture of the Code tab of the type library editor:







If you know IDL you'll find that RIDL isn't really any different. In fact it has been our goal to make sure that midl.exe can compile .ridl files. So we didn't make up our own language here, it's industry standard.

15 comments:

Dmitry Streblechenko said...

Chris,
will we be able to convert existing TLB files to ridl files for existing projects?

Chris Bensen said...

Dmitry,

Good point, I should have mentioned the upgrade experience...Yes, when you open an older project the upgrade process will convert the .tlb to a .ridl file. If for some reason that process fails or you want to do it by hand, we have options on tlibimp.exe to convert a .tlb to a .ridl.

animal said...

Whoa!
Now I'm really pumped for Tiburon! ;)

Sure, generics and anonymous methods are already really cool in theory but I still have the work of coming up with actual use cases ahead of me... not so here. This is the first new feature I can see immediate benefits of! This will make me more productive from the very second the installer will have finished. Thank you very much!!! :)

Is any hope justified that the type library-related files (including the *_TLB.pas!!!) will also no longer get rewritten and modified on every single compile or project save? That is currently the other major PITA besides the binary TLBs...

Cheers,

Oliver

Chris Bensen said...

Animal,

There aren't any plans to turn off the management of the _TLB.pas file, but we do handle it a bit differently now. With the RIDL system the _TLB.pas file won't be regenerated each and every time you do something. What currently happens is the _TLB.pas file is updated whenever it is older than the .ridl file, just like any other build system would do with a .dcu or .obj. Does that solve your problem?

Also, in theory you shouldn't have to place the _TLB.pas file into version control. It is all based off the .ridl file...I haven't tested that yet but it should work.

Thomas Mueller said...

So, .ridl files are text, right? Does that mean we can finally stop putting binary .tlb files into source control and instead have them regenerated from the .ridl when necessary?

animal said...

Chris, I did not mean to turn off _TLB.pas management. I just don't want it and the .tlb to be regenerated on every compile (especially not with an "Imported on ..." timestamp that keeps putting it into modified state in my VCS).

Another minor annoyance for me at the moment is that not only does it keep rewriting the _TLB.pas, but it also keeps adding the component wrapper code to it which I do not want and which I had explicitly deselected on project creation (and it didn't create it then - it only keeps re-adding it now).

@Thomas: I think that's the whole point, yes.

Anonymous said...

Excellent!
I remember having to manually redo a lot of changes to a tlb that seemed to have been entered ok before, but that caused corruption of the tlb on a later change. And it really was a PITA working with a team of developers on a single tlb. In fact that was a major contributor in driving us to a completely different remoting systems (TIBCO RendezVous).

Anonymous said...

Another reason to buy Tiburon from Embarcadero, with the bonus of not giving a penny to Borland. I'm very happy with features introduced in Tiburon. Hopefully I can use CodeGear C++ components in Delphi projects someday, too.

I've decided to buy Rad Studio 2009 (Tiburon) because I like what's been done in version 2007 and upcoming 2009 -- unless Tiburon is buggy.

I hope that Tiburon is as stable and fast as:

Rad Studio 2007 patched with
+ December Update
+ Apr 08 Hotfix
+ Jun 08 ilink32
+ DelphiSpeedup 2.78
+ IDEFixPack 1.6

If the bugginess comes back in Tiburon, I'm forced to say goodbye and join "the dark side" aka Visual Studio 2008.

You have no idea how much I'm hoping for a stable and fast Tiburon.

All eyes are on this release to see what Embarcadero's impact will be on CodeGear quality and innovation.

LDS said...

RAD 2007 stable! ROTFL! It just trashed a type library because I changed a parent interface and then refused to close, keeping on throwing a "Duplicate ID in inheritance hierarchy" exception but not handling it at all. Really hope the new editor works better - it was broken after D7 and still is.

Anonymous said...

what's the difference between .idl and .ridl ?
where is any reason to introduce new extension instead of usual ".idl"?

Chris Bensen said...

LDS,

Bummer, I'm sorry to hear that. Can you narrow the bug down to some simple steps so I can test it in Tiburon?

Chris Bensen said...

Anonymous,

Good question. RIDL is a subset of MIDL. We had to distinguish it being different for two reasons. .idl files in the IDE are associated with CORBA and we currently don't have a preprocessor or an expression processor. There are a few other quirks but MIDL supports everything we support so we wanted to differentiate it.

Anonymous said...

This release will not be successful. Maybe a little, but they you to change the entire IDE to something unique and different.

Alistair said...

Can you publish the grammar for RIDL? We have internal tools that automatically generate interface definitions and TLB files from Delphi source, and these tools will have to be rewritten to generate RIDL before we can migrate to D2009.

Chris Bensen said...

Alistair,

RIDL is MS IDL without a proprocessor or an expression parser. So just look at the MS IDL spec.

Post a Comment