Creating an IE plug-in

I was recently approached by a customer about an intriguing project, unfortunately I can’t tell you too much about it since I’m under an NDA, but it involved creating an add-in for Internet Explorer and a custom Windows Service which would act as the backend. I’ve never created any add-ins for IE before but as a long time Windows developer I know that the Microsoft web browser is heavily dependent on COM. Since I’ve been doing mainly .NET development for the last 10 years or so, and sort of left the COM world behind me, I first started looking for some form of framework that would allow me to develop the add-in using managed code.

I found two different frameworks that I started evaluating. The first is an open source project originally created by Microsoft called SpicIE and the second is a commercial product called Add-In-Express for Internet Explorer. The latter is from the company Add-In Express Ltd who has specialized themselves on creating add-in frameworks and has a wide range of products to create add-ins for Office and IE in both .NET and in VCL for Delphi.

Both of these frameworks takes care of all the COM communication and implements all the necessary COM interfaces so you can concentrate on the more important things, namely what your add-in is supposed to accomplish.

In my case I needed to be able to create a toolbar button and an IE bar, which are those side panes similar to how Favorites and History are displayed within IE. There was no problem creating these in either framework but the Add-In-Express also had an Advanced IE Bar control with some additional features which I liked a lot. They also have visual designers which simplified everything and I was able to create a stub application, that demonstrated the final design, within a few minutes. It took me a bit longer to do the same using SpicIE, mainly because the documentation is a bit sparse (as the case often is with open source projects), but it comes with several demo projects that you can learn from. Add-In Express on the other hand have several video tutorials available on their website, which of course is a lot faster way to learn the basics without digging through a bunch of source code.

SpicIE also comes with this reservation:

Important: SpicIE is released independently of Internet Explorer and related products. It is not an officially supported product by the Internet Explorer team. While SpicIE is a valuable tool for prototyping and testing Internet Explorer extensions, it is not recommended for use with released software.

For me there was no question about which framework we would use for this particular project and if you would ever need to create a commercial product that requires an add-in for Internet Explorer I highly recommend Add-In Express, you’ll get a very stable product and excellent support from the team at Add-In Express Ltd, but this of course comes with a price tag so if you’re just a hobby programmer then go ahead and give SpicIE a try.

The next thing we needed to do was put a team together to start developing this particular system. Since the customers budget was rather tight my manager decided that we should use our offshore company in India for the development of the actual add-in while I should concentrate on the architecture and create the backend system.

I think I have to write a blog post about the experience I’ve had with this and other projects when the development team sits in different continents, with different cultures and in different time zones. It’s both exciting, fun, and very frustrating at the same time, but that have to wait for some other day.

Have fun!

Digg This

Visual Studio 2010 SP1 Beta released: Great news for VB developers

Today, Thursday, December 9, Microsoft is releasing the beta version of the Visual Studio 2010 Service Pack 1 to the public, MSDN subscribers have had it for a couple of days now. It has a Go Live license, so even though it is a beta release you can use it in your products today. Apart from many tweaks and bug fixes it also contains several cool new stuff:

  • Intellitrace for 64-bit and Sharepoint.
  • Silverlight 4 tools.
  • Local help viewer.
  • Performance Wizard for Silverlight.
  • Unit testing on applications targeting the .Net 3.5 Framework.

All of the above features are great and you can read more about those plus many of the bug fixes and also find links to the downloads on Brian Harry’s blog. However in this post I’m going to spend some time on one particular new feature that, I think, will bring great joy to all VB developers around the world. It is also a big step towards the goal Microsoft has put up to bring language parity between the VB and C# languages. This new feature is simply called: VB Compiler runtime switch.

History Lesson

Visual Basic has a long history, the first version of Visual Basic was released back in 1991, but the history of the language goes back even further than that. VB1 was the first RAD tool for creating Windows applications and created a new way of programming by drawing the user interface using a control toolbox. But the actual language syntax was an extension of the older QuickBasic language.

So VB had a large baggage even before the release of the first version of VB.Net or VB7 back in 2002. At that time the language went through a large transformation, so large that many people didn’t even recognized their favorite language anymore. I must admit that I was one among many that felt the transition to this new framework was painful, not so much because I had to learn a new framework because I enjoyed that part (and I still love to learn new programming languages). The reason was simply because it wasn’t backward compatible and it was a pain to convert an older VB6 application to use the new framework.

Microsoft did their best to make the transition to .Net as smooth as possible and added a lot of legacy functions in the Microsoft.VisualBasic.dll assembly, such as Left(), Mid(), Right(), Chr(), ChDir(), MsgBox() and so on. These functions aren’t really necessary since there are other ways of getting the same result, but it made the transition from VB6 a lot smoother.

A lot of other stuff was also added to this assembly, such as the ability to use late binding (with Option Strict set to Off) and later on many of the My namespace features points to methods within the Microsoft.VisualBasic assembly.

Other “features” also included in this assembly are On Error Goto and On Error Resume Next that still works in VB.Net. The main reason those are kept is probably because the Upgrade Wizard (that existed in versions prior to Visual Studio 2010), that converted VB6 code into VB.Net (at least partially), should be able to work. It’s to hard for a software wizard to convert On Error Goto and On Error Resume Next statements into good Try…Catch blocks.

So what does this have to do with the new compiler switch?

There is nothing wrong with the fact that VB has its own runtime library, after all C# and Visual C++ also have their own runtime assemblies. The difference is the size of these assemblies and what they contain. The Microsoft.CSharp.dll, which was added in .Net 4, contains the runtime builder that adds support for the dynamic keyword, while Microsoft.VisualBasic.dll contains a lot more, as discussed in the previous section.

- So does it matter?

No it doesn’t. At least not if you only want to write code for platforms that include the full .Net framework, such as desktop applications for Windows or ASP.Net applications for the web. But there are other platforms that doesn’t include the full framework, such as Windows Phone 7 or XNA for creating games that runs on the XBox. There can also be other third-party platforms that only contain parts of the .Net framework. When you have limited space for a custom implementation one of the last things you might want to add is the large Microsoft.VisualBasic.dll assembly.

- So what? If I don’t use any of the legacy functions, don’t care about late binding, and always use Try…Catch instead of the terrible On Error statements, why would I need this assembly? Can’t I write VB code without it?

Yes, you can. However the assembly is always referenced by default as soon as you create a VB project, but you can actually remove the reference when you compile the project. However you would need to use the command line compiler to do so. But (and yes there is a but and a rather big one) there is a problem with removing the VB assembly and the name of that problem is the CType operator.

Since CType is an operator and not a function the conversion will be done inline at compile time, or rather the compiler will try to do it inline but that is not always possible. Converting an integer to a double can easily be done during compile time but converting the generic System.Object to a less generic type is not possible until run-time. So there is a helper function in the VB assembly that does the conversion for you, but it can of course only do that if the assembly is available and you have a reference to it.

So the /vbruntime switch, that has existed in the command line compiler (vbc.exe) for a long time, has now been extended. Instead of just excluding the runtime assembly or using another assembly as the runtime, it will now be able to include the key VB runtime as a reference into your application. This will be a great help to get VB support faster for new platforms.

- So will we see VB support for the XNA platform anytime soon?

Well, it might not be that soon since apart from this compiler switch it will also require new templates, a lot of testing and so on, but yes, I think we will be able to use VB for XNA development sometime in a not so distant future.

Have fun!

Digg This

VB and F# support on Windows Phone 7

Have you also heard the rumor that VB and F# is not support on the new Windows Phone 7? Well, Justin Angel, a Silverlight expert, disagree and in this post on his blog he showed that you indeed can use those languages to develop WP7 applications. Check it out it’s a pretty cool workaround.

I must admit that I was a bit skeptic at first since the normal problem with supporting VB on a device that only implement a part of the .Net Framework (such as XNA for writing games for the X-Box) is to include Microsoft.VisualBasic.dll since it, as opposed to Microsoft.CSharp.dll, has a lot of references to other parts of the framework which might not be included in the limited version.

Now, it is actually possible to remove the reference to Microsoft.VisualBasic.dll in a VB project if you use the command line compiler but the problem with doing so is that the CType operator in some cases must use it. Yes, you read it correctly, CType sometimes need to do the conversion during run-time and must then call an internal function in Microsoft.VisualBasic.dll. If you, for example, would convert an integer to a double that would then be handled at compile time and the conversion would be inline but if you would want to convert an Object type to any more generic type the conversion can’t be handled by the compiler and then the internal VB.dll function will be called during run-time.

Well, according to Justin this is not a problem on a WP7 device since Microsoft.VisualBasic.dll is part of the Silverlight 3 distribution which has been ported to WP7. So this leads to the question why we don’t have “pure” VB support on the WP7 device today? Microsoft has said that VB support is coming but the question still remains.

Anyway, in the mean time, as Justin showed in his post, there is a simple workaround.

Thank you Justin (and an extra thank you to Jim Wooley for mailing me the link to Justin’s post)!

Have fun!

When OOP stinks and when you instead should leave a smell behind…

I just saw an interesting video blog post by the CTO of Devexpress entitled Pac-Man and Object-Oriented Programming, in which Julian talks about how we’ve been doing object-oriented programming for 20 years now (or even more than that if you come from the SmallTalk world) and how we, as OOP/OOD programmers and designers think about programming. He then quickly moves on to comparing that to a game of Pac-Man.


Now Pac-Man was a great video game developed by Namco in Japan back in 1979 and it was released in Europe and the US the year after. The game was an instant success, maybe because it was different from most of the other video games of the time, such as Space Invaders, Galaxy, and Asteroids, which was mainly shoot ‘em up games in which you should kill and/or destroy everything you saw (much unlike video games of today where we have 3D FPS games in which you walk around and kill/destroy everything you see… Oh, wait there isn’t that much of a difference, is there?). In Pac-Man you play this pie-chart looking character that walks around in a maze eating dots at the same time as you’re trying to avoid getting caught by one of the four colorful ghosts that are, for some reason, hunting you.


Whoops… Sorry! I got a bit nostalgic there for a moment and sort of strayed away from the topic. This blog post was supposed to be about object oriented programming and design and not about gaming. So let’s get back on track, shall we?


If you, as an OOP developer, would design the Pac-Man game today, how would you go about it? You should probably create a class for Pac-Man and another for the ghosts that hunts him. Well, they might actually be subclasses of a common character class since they do share some very basic logic such as they can’t walk through walls and other basic elements that you can think of. But they would still be 2 different classes. You might also have a Maze class that draws the actual maze and have some other logic like knowing which level you’re playing and such. The dots and power ups might also be different classes.


But the logic of the ghosts aren’t that easy. How will they go about to chase Pac-Man? They obviously need to know about his position but how do you calculate the closest path to get to him? The ghosts can’t go through a wall so you must calculate the nearest path around the maze. Doing that in every game cycle on a modern day computer is not such a big deal, but Pac-Man came out back in 1979 and the CPUs used at the time couldn’t do that and still produce a fast pacing game.


The solution Julian suggested was that maybe the ghosts in the game are like blood-hounds and Pac-Man is given away a scent as he moves around in the maze. The square in the maze Pac-Man just left gets a value that as Pac-Man moves on decreases in value until the scent has evaporated. This way the ghosts has no real knowledge about Pac-Man at all since they are just following a scent. The scent itself is now a property of the maze object and not of the ghost object. Julian called this anti-object oriented programming since the logic is not in the “real-world” object of the ghost (is that really a real-world object?). So by changing the logic of the ghost not to actually hunt Pac-Man but to follow a scent when they find it and also added some logic to the maze class, the anti-object, which you probably only used for drawing before.


I love this example since it’s an example of thinking-out-of-the-box when it comes to OOP and OOD. Instead of always trying very hard to make the classes as close to real-world objects as possible make a few changes and simplify the whole idea.


To be completely fair here, this is actually not how the AI of the ghosts in the original game was designed. If you’re interested I invite you to read the Pac-Man Dossier especially chapter 3 and chapter 4 that explains how the actual AI for the ghosts was created. But the fact that the actual design was different is beside the point. Julian showed a simple solution to a hard problem you might face when you’re doing object oriented design.


Have fun!

Microsoft is switching the light but will it turn on or off?

During the VSLive! keynote in Redmond, Microsoft yesterday announced a new Visual Studio product called LightSwitch.

LightSwitch is a new SKU for Visual Studio that will allow people to create line of business (LOB) applications for the desktop and the cloud without writing a single line of code. It will also be shipped with future version of Visual Studio Pro and above. In a way it reminds me of Access but with the difference that it can use different data sources, including Sharepoint and Azure SQL. Since the announcement there have been a wild discussion within the MVP programmers community, especially among VB and C# MVPs if this is a good or a bad thing.

We have seen tools like this before that are aimed to power users who aren’t full-fledged programmers and when a professional programmer have to take over the project it’s a mess with business logic code mixed up with UI code and data access code. I have not yet made up my mind if this is good or bad, but I do see some great opportunities with LightSwitch. Since it generates .Net code, in either C# or VB, and that it does seem to use an n-tier design I feel that this tool might become very successful. Of course we have to wait until the public beta is released later this month before we can actually see if the generated code lives up to the high standard professional developers demand.

Some of the discussion has questioned if this should have been released as an Office tool rather than as a Visual Studio SKU and even though that is a valid point I truly feel that the fact this tool is made by the Visual Studio team rather than the Office team the code generation will be better since the Office team isn’t really interested in creating development tools but also that more professionals might use this for prototyping or getting a quick start application that they continue to build on. If this will be the actual usage of the tool I don’t care if a power user instead of a programmer does the initial prototyping.

In either case I’m looking forward to giving LightSwitch a try as soon as the beta have been released. Several videos will be released showcasing LightSwitch during the next few days/weeks on the LightSwitch home page. Have a look and make up your own mind. Jason Zander, who held the presentation at VSLive, also wrote an excellent blog post about LightSwitch that demonstrates what it does and what it can be used for.

So what do you think? Are tools that hides the complexity of programming a good or a bad thing? Feel free to leave a comment.

Have fun.

Visual Studio 2010 Beta 2 released

Yesterday Microsoft had a big announcement day. At the same time as Steve Ballmer held his keynotes at the SharePoint Developers Conference (see the video) Microsoft released Visual Studio 2010 Beta 2 for MSDN subscribers, the public release will be tomorrow, October 21st. They also announced that the official release date of Visual Studio 2010 and the .Net 4.0 Framework will be on March 22nd, 2010.

Visual Studio logo Visual Studio has been given a new blue-purple logo and at the same time the MSDN web site has also been given a face lift using this blue-purple color scheme. If you have visited the Visual Basic Developer Center recently you may have already seen the preview of the new MSDN look. In my opinion it’s much nicer compared to the old red color scheme it had before.

With the beta release Microsoft also released Visual Studio 2010 Tools for SharePoint.

Microsoft have compiled a lot of 2010 resources on the VB and C# Developer Centers: VB 2010 Resources, C# 2010 Resources. They have also released a number of How do I videos. Note, the first two links will be available very soon, if they aren’t already.

I have looked forward to this beta release for a long time now, even though I have used Beta 1 since it was released back in May, beta 2 is much more promising simply because everything should be in place by now. Microsoft will probably not add any new features but rather just fix any bugs that are reported and concentrate on performance issues. So I can now start doing some real world testing and finally concentrate on to fully learn the new features of the framework. This of course also means that you can expect to see a lot more posts about VS2010 on this blog in the near future.

Have fun, I know I will. :)

Award time

On October 1st, I was re-awarded as a Microsoft MVP. In fact I almost missed the e-mail since it ended up in my junk e-mail folder. :)

image

This is the third time that I receive this award and it’s a recognition of my commitment to the programming community and a great honor.

To comment or not to comment

Introduction

Anyone that has ever taken a programming class or read a beginners book on the subject know how important it is to write comments in your code. But is that really true? In this post I’m going to discuss/question the common practice of writing comments in your code.

Bad comments

A couple of weeks ago I was contacted by an old friend of mine that runs a construction company. They have an old custom system that they’ve had since the mid or late ’90s sometime. He wanted some slight modifications made to this system, but the consultant business that created it apparently disappeared sometime during the dot-com death era. So he wondered if I could have a look at it and come up with an estimation of how much work it would require to do these customizations he needed.

Since he had all the source code – and because I’m such a nice guy – I asked him to e-mail the source over to me, which he did. When I opened up the old project (which was written in Visual C++ 6.0) the first thing I saw in the main file was this (the name of the developer and company have been changed to protect the guilty).

/***********************************************************************************
*
* File name   : CGMain.cpp
* Developed by: John Doe
* Company     : Former Dot Com Inc
* E-mail      : john.doe@nowheretobefound.com
* Date        : 1997-03-21
* Requirements: None
*
*-----------------------------------------------------------------------------------
* Version history
*-----------------------------------------------------------------------------------
*
* 1.0.0 Initial release
*       1997-03-21
* 1.0.1 Minor bug fixes
*       1997-03-24
* 1.0.2 Added 2 functions: AccViewF() and AccViewT()
*       Reason: The customer needed to store the AccView creator and delivery
*       1997-04-03
* 1.0.3 Minor bug fix
*       1997-04-05
* 1.0.3 .... This goes on and on ...
*  ...
*  ...
* 1.2.7 Minor fix
*       1998-04-02
*
***********************************************************************************/



I can assure you that the list was lot longer than what I posted here. What is this good for? Why does a file need a comment header that tells me the name of the file? I already know which file I opened. Do I really care who wrote it? I don’t know that person and the contact information isn’t correct anyway. Could somebody explain to me why you would need a version history typed into the file? Ever heard of source control systems? Those are made to keep track of different versions of your file. The above comment doesn’t bring any useful information my way, or to my friend who isn’t a developer and because of that never even looked at the source code. All it did was made me scroll down a page or two before I got to the actual code.



I can understand that a company that sells class libraries and components with accompanied source code might want to add a (hopefully short) copyright notice on top of each file, but other than that there is really no reason why you want to have a commented header in your file.



When to add comments and when not to



In .Net there is one type of comments I always recommend people to use and that is XML comments. Those are great when they are added to methods and properties of a class library. A library, I might add, that you probably never open up the source code for, at least not if it comes from a third party. The XML comments aren’t meant to be read by humans, they are read by the compiler and shows valuable (hopefully) information in IntelliSense tooltips. Other helpful comments are JavaDoc and PyDoc comments used respectively in Java and Python to create documentation.



I remember once reading a blog post by Jeff Atwood about this very subject, please hold on while I Google it for you……. ah, here it is. Jeff also wrote a long rant about header comments, much like the one above. However in his post he, more or less, said that you shouldn’t use comments at all, which I don’t fully agree with him on. But he has a very important point which I think is also an excellent advice, always aim to write, or refactor, your code so it doesn’t need any comments. With that I (and I think also Jeff, even though I can’t really speak for him) mean that you should always give your methods a very descriptive name, keep them short and to the point.



But unlike Jeff I still think it can be valuable to sometimes stick in a short comment that explains what the code is doing. However you must remember that the comment is then as important as the source code. If you refactor or change the source it is important that you also update the comment. Nothing is as useless as a comment that isn’t valid anymore.



A while back I saw the following comment in the code behind file of an ASP.Net page.



'TODO: The following code is very resource-intensive and
'      should be refactored.



The page that contained this comment had been in the web application in question for years. I looked at the code and couldn’t figure out what it was that was so resource-intensive. I stepped through it, and analyzed it very carefully without finding anything special. So somebody must at some point have done what the comment said, but without removing the comment, which made me waste my time to analyze perfectly working code for no reason at all. Here’s another comment from the same project.



'This is probably not a good idea, 
'and should be changed but I’ll leave it for now.


Excuse me while I scream and swear… (this text has been censored). What is it that isn’t such a good idea? How am I to know how the original developer was thinking when he wrote the above comment? Did he have a brilliant idea how the code could be refactored but was to lazy to do it now? Has he refactored the code but yet again forgot to remove the comment?



The point here is to never write comments that only make sense to yourself. Code is written once and read many times. Much of the code you write today are legacy tomorrow when you aren’t around anymore and some other poor sob have to update it. Always edit or remove comments when you edit the source.



At this point it probably sounds as if I think you shouldn’t write any comments at all with the exception of XML comments, but that is not the case. As Joel Spolsky have said: Code is easier to write than to read. That is so true. How often haven’t you looked back at some code you wrote just a couple of months ago and wondered: How was I thinking here… Not that you weren’t thinking when you wrote it, the code is probably just fine, but at the moment you can’t remember the flow of the source. When you develop you are in the middle of it and probably know exactly why you should call that particular method from this particular place, but a few weeks later (after you’ve been working on something very different) when you revisit your older code you just can’t remember that flow. So it takes a while before you are up to speed with it again. Now, what if that isn’t you that revisit your old code? Somebody else that thinks in a different manner than you will have a much harder time to get the flow before he/she can be productive with your source. This is the main reason why developers want to work on new projects all the time. We usually don’t like to work with old legacy code, especially old code we haven’t written ourselves.



In those cases a few well placed comments might help a lot. Just keep remembering that you need to refactor the comments just as much as you need to refactor the source code.



End words



There are one type of comments I do enjoy to read, and that is your comments on my blog posts. :)



Have fun!

Copy and Paste programming – A bad habit

Introduction

I usually stay away from religious discussions when it comes to programming habits and technology choices simply because they don’t usually make any sense at all and are most often just based on emotions. Arguing if VB.Net is better or worse than C# is just nonsense in my book since the differences between them are minor. They both target the same platforms, and use the same framework, of course there are differences but none of them are so great that you would say that this is a much better language. I personally think that XML literals in VB are great but that alone doesn’t make VB a better language. It is just easier to handle XML in VB, so if you do a lot of that VB is a better choice for that particular purpose. I also like the ease with which C# handles iterators, but again that doesn’t make C# a better language, it just make that particular code part easier.

imageAnother discussion I often see on the Web is if the Java J2EE framework is better or worse than the .Net framework. Again this just stir up emotions, if you’re a Java programmer you would of course say that Java is better than .Net and the other way around. It’s not true though… Java is not better than .Net and neither is .Net better than Java. It all comes down to which platform you’re targeting and what the requirements are for the project at hand.

Is an axe better than a saw? No, they are both exceptionally bad tools – if you’re trying to nail two pieces of wood together, that is. In that case you should use a hammer and not an axe and definitely not a saw.

Having said that, this post will still be a rant about a thing that really grinds my gears, copy and paste programming.

Why you should ban Copy and Paste 

I want to start by making one thing very clear, I do not think it’s a bad habit to copy a great piece of code you find somewhere on the web and then paste it into your project. As long as you test the code and perhaps refactor it to fit your naming convention then that’s just fine. What I talk about is the habit of copying and pasting the same code all around a project or even between different projects. Come on! If you’re reading this blog there’s a big chance that you’re a .Net developer and as such you use a modern OOP language. The whole purpose of object oriented programming is to create classes for code reuse and to preserve encapsulation. Even if you’re using a structured programming language you can still refactor your code so that you don’t have to repeat the same thing over and over.

Even though older code might be well used and therefore perhaps less buggy doesn’t mean that it will stay that way. Business rules changes and if you need to change how a particular piece of code works you should only need to do that in one place. Also, if the code does contain a bug, you have just introduced the same bug in another place. The next time you feel the urge to copy some code think again and cut it instead. Cutting the code and pasting it elsewhere means you’re refactoring your code and refactoring (to paraphrase Martha Stewart) is a good thing. Cut the code, paste it into a new method and call that method from the place the code used to reside.

If you’re working on a WPF or Silverlight project you don’t even have to copy and paste common XAML code, use a ResourceDictionary instead. But that’s design code, it’s much more important to not copy and paste business logic or data access layer code to different places.

Conclusion

What do you mean conclusion?
Haven’t you paid attention?
Stop copy and paste code! :)

Have fun!
kick it on DotNetKicks.com