View RSS Feed

Development Team Blog

Sometimes it's better to Just do it: Examples

Rate this Entry
As soon as the previous article was published, I realized that some examples would go a long way to illustrate the point. Of course, I wrote it a week ahead, but didn't think of adding examples until the same day it was published... Oh well, we've all been there... So here are some real-world examples of what I was talking about.

Start Center
A few years ago when the Start Center in the Studio was first introduced, I was only involved in that project at a high level and not with the actual coding part. So one day I got a question from one person working on the project: "I want to figure out if we're connected to the Internet, do you know how I can do that?". I thought to myself: "That's a bit of a strange question.", so I asked "Why would you need to know that?". And the answer was "Well, I'm working on the Start Center, and if it can't connect to the DAC web site, you get the ugly Page cannot be found error, and it leaves the Studio looking completely broken. So I want to detect if it's connected to the Internet first, and only then try to display the Start Center web page."

Now, ignoring the biggest problem of what "connected to the Internet" even means (you have an IP address? You can connect to google.com? Or whatever other strange test you can think of), it doesn't even answer the real question of whether the DAC web site will respond to the request. At first glance it really seems like a good approach, but when you look at it closer you realize it's almost impossible to answer, and it still doesn't really provide any guarantees that the web page will be properly displayed in the Start Center.

So I said: "That's easy, you don't." Instead of trying to find out if you're connected to the Internet, and then hoping that it will then mean that accessing the DAC web site will work, you should Just do it, access the DAC web site as normal, and if it didn't work you can then react to that and display something else in the Start Center. If it worked, it worked, there's nothing else to it. If it didn't work, then there's no question about it, it really didn't work, no chance of false positives. I don't remember the exact details, but in that particular case I believe there was an event in the web browser control that you could use to figure out if the url navigation didn't succeed.

The above happened many years ago in the development of the Start Center for the old IDE. In the latest incarnation of the Start Center it's evolved even further, still with the same philosophy of Just do it, rather than testing to see if it will hopefully work. It now stores a locally cached version of the Start Center content. The cached version is first displayed, and then the Studio fetches the dynamic content via a web service in the background, rebuilds the content with XSLT scripts and stores the updated cached files, and then refreshes the browser window with the locally cached content. If the web service call fails, it will just continue to display the old cached content, and nobody even notices.

ActiveX Control Registration
When the Crystal Reports support in VDF was switched over to the COM interface I got the question "How can I find out if a particular control is properly registered?", and I thought "That's a strange question.", and of course asked "Why would you need to know that?". The answer was "Well, if the Crystal Reports control is not properly installed, the instantiation will fail and you get a bunch really ugly error messages.". My reply was of course "Well, that's easy, you don't".

Just as above, there's basically no way of knowing if it's "properly" registered, as it all depends on the control itself, I have no idea what all the dependencies of the Crystal Reports control are (and I'm sure that list would be changing all the time). And even if it's properly registered, that's no guarantee that instantiating the control will work, there could be permission issues, or files could be missing or whatever.

Instead it's much better to Just do it, instantiate the control as normal, and check for the error. If it worked, it worked, nothing more to it. If it didn't work, you can then display a friendly error message, knowing full well that there are no false positives since if it failed, it really did fail, no question about it.

You can then enhance the error handing after you already know it didn't work, by for example testing for the presence of registry entries or files or something, to suggest possible reasons for the problem or potential solutions.

Vista Support and UAC
Just a few revisions ago when we added support for Vista, we ran into a similar situation with UAC and file permission issues. There are certain things that you cannot do within the Studio when you're not running in elevated Administrator mode with UAC on Vista. For example, you can't modify files in the standard VDF installation directory within the Program Files directory.

The question again was raised: "How can I find out if UAC is enabled and you have elevated Administrator privileges so you can modify files within the VDF installation directory?". And by now you know my answer: "That's easy, you don't." Just do it, save the file as normal and check for an error. If it worked, it worked, and it doesn't matter if you had elevated rights or not, it just worked. If there was an error, you can display a more friendly error message, and then suggest that a possible reason for the error could be that you're not running with elevated Administrator privileges.

In Summary
It's all so obvious, yet we're often drawn to the approach of testing something else first, hoping that it means whether the real thing will work or not. Let's say there's a function called CopyFile(), which returns True or False whether the copy operation worked. Instead of just calling the function and see if it worked, we decide we should ignore the return value, and write some new code to test if we think the copy operation will work before we call it, testing if it's a valid drive letter, checking the paths etc. That's just silly! And yet, the above problems are really not much different, just a little more complicated and less obvious. Sometimes you really do need to do some tests up front, but most of the time it's better to Just do it.

Updated 1-Feb-2010 at 08:05 PM by Sonny Falk

Categories
Uncategorized

Comments

  1. DaveR's Avatar
    Which is why Try..Catch is so useful, now that the OS group have provided it...