Partager via

C# vs. VB for Office development (part 2/?)

  • Article

Turns out there's another way that VB tends to make Office development nicer. And that's because office uses late binding in a few places (dialogs were mentioned as one of those places). So in VB you could type something like:

 
Dim dialog as OfficeDialog
dialog = GetDialogSomehow()
dialog.Font = "wingdings"

Whereas in C# that would become:

 
OfficeDialog dialog;
dialog = GetDialogSomehow();
typeof(OfficeDialog).InvokeMethod("Font", BindingFlags.Public | BindingFlags.Instance, null, new object[] { "wingdings" }, null);

Yech. One interesting thing to realize is that by forcing explicit late binding in C# we force it to your attention that this might fail. At least, we try to make it pretty clear since reflection can end up throwing a whole host of exceptions. In the VB model that call seems completely innocuous and you wouldn't think to wrap that in a try/catch block.

Anson and I talked afterwards with the presenter. I asked: Wouldn't it make more sense to have something like this:

 
IDialogWithFonProperty d;
if ((d = dialog as IDialogWithFontProperty) != null)
{
      d.Font = "wingdings"
}

I.e. have nice safe interfaces/subclasses that one can cast to and get compile time checking on.

Anson's reponse was more general. He asked: Wouldn't it make sense for Office to provide a nice managed interface (a primary interop assembly) that fit well in with the .Net languages and abstracted a lot of these old design patterns away from the user.

The speaker thought that both ideas seemed good and that it was something they would look into trying to do.

Comments

  • Anonymous
    May 28, 2004
    Of course, this will not work in VB.NET either if Option Strict is On. And there's no GOOD reason to ever turn it off.

    Why isn't it the default???

    Chris J. Breisch, MCSD, MCDBA
  • Anonymous
    May 28, 2004
    Late binding is a powerful feature, which makes VB more dynamic.
  • Anonymous
    May 29, 2004
    Fan: How does late binding help help here? Either the call will succeed, in which case casting it ot the interface would succeed, or the call will fail with an exception and you will have to clean that up. Why would you prefer failing at run time as opposed to knowing at compile time that something was wrong?
  • Anonymous
    April 02, 2008
    原来做过一个小的win程序操作Excel的被那些个参数搞的头晕晕的那么多Missing啊今天在Blog.Msdn.com看到关于VB和C#在office开发中的比较的讨论 http://blogs...