# Saturday, September 13, 2008

Or put another way, is VB just C# without semi colons? Well, yes and no. If you work in the big wide world of many different programming languages, frameworks, libraries, and operating systems then C# and VB are so close as to be almost indistinguishable. They both have great support from Visual Studio, they both produce managed code that runs on the CLR, they call the same framework functions, they have keywords for the same CLR concepts, and they both have a community of support, sample code, tutorials and the like. But those communities aren’t twinned – some samples are available only in VB, and others only in C#. For historical reasons there are a lot of C# programmers inside Microsoft, and perhaps that’s why VB samples can be a bit thin on the ground.

This less-than-100%-overlap between the samples, tutorials, and so on for the two languages results in people who are proficient in one language trying to read (or worse, write) in the other. Sometimes a great C# developer will be asked "where’s your VB sample? Quick, translate your C# one right away!". Other times a great VB developer will be trying to write their own VB code while reading samples or tutorials written in C#. It can go in the other directions, too.

But although these two languages have a great deal in common, they are different, and in more than just syntax. There are features in each that aren’t in the other. There are natural idioms, too. Idioms are a way of writing things that are natural to one language or identifiably belong to one language. Choosing an example not from the VB/C# world, but from C++ or C, it used to be just so normal to write

if (p=SomeFuncThatMightReturnNull())
{
//do something that relies on p not being null
}

That’s C++, and a deliberate single equals sign. I am assigning p the return value from the function. Then I am testing that value. (Quibble: I am testing what the = operator returns, which is the value just assigned for all well written = operators.) If it’s not null, we’ll do the stuff in the braces. Sometimes I used to come across this instead:

p=SomeFuncThatMightReturnNull();
if (p)
{
//do something that relies on p not being null
}

Or even

p=SomeFuncThatMightReturnNull();
if (p != null)
{
//do something that relies on p not being null
}

Now these other ways of doing it aren’t wrong, they will compile and work, but they demonstrate a lack of familiarity with C++ idioms, with a C++ way of thinking. They are usually written by people who aren’t very comfortable with pointers.

Similarly, in VB, I have seen more than once this sort of thing:

        Dim retval As Boolean = False
        If x > y Then
            retval = True
        Else
            retval = False
        End If
        Return retval

Again, that’s not wrong exactly, but it’s not what I like to write. I prefer just:

        Return (x > y)

Sometimes people say I write C++ in VB, because that's a very C++ way of writing things. But I find it not just easier to read -- it's less bug-prone. (Copy and paste errors like having True in both clauses, for example, will make you crazy.) I know that it’s kind of a C++-ish way to express myself, but it feels natural to me and it works. People who are less comfortable working with Booleans tend to prefer the first, more verbose way. They can see the whole thing laid out for them. It’s not wrong, just different.

Well, it turns out those who try to write VB when they’re proficient in C# are likely to run into a lot of differences in thinking and expression when they take on that task. It might be syntax tripups, missing the use of a helpful VB feature that isn’t in C#, or just writing code that doesn’t use the VB idioms. Kathleen Dollard has amassed a huge list (77 at the moment) of things you should know if you want to write VB code. Required reading for C# people who have to write VB, entertaining for those who like VB, and what's more, plenty of experienced VB developers could learn a thing or two from it (I did.)

Kate

Saturday, September 13, 2008 11:26:18 AM (Eastern Daylight Time, UTC-04:00)  #    
# Friday, September 12, 2008

Vista gets a lot of bad press it doesn’t really deserve. For example, it crashes way less than XP for me. Some applications behaved oddly at first (primarily because of UAC and Virtualization) but I have either learned workarounds, such as running the app elevated, or upgraded or replaced the apps that were causing trouble. The slow file copy thing drove me insane, but SP1 took care of that. I really have very few complaints left about my computer, and the ones I have are aimed at specific applications (yeah, Outlook 2007, I am looking at you when I say that, and Adobe, don’t think not meeting my eyes will keep you out of my bad books) rather than the operating system.

Still, who wouldn’t want to make their operating system run faster and smoother? Here are some helpful thoughts and guides:

Windows Vista Performance and Tuning. A downloadable paper from Microsoft. Simple stuff here like choosing the right power management plan, using ReadyBoost, tweaking your search settings, and so on. Worth a read.

Vista Annoyances Resolved. Despite being annoyingly spread over 9 pages (see what taking ads does to you?) it has some good stuff. You’ll see explanations of SuperFetch, ReadyBoost, restore points, and more.

Roundtable with Mark Russinovich. An upcoming special roundtable on Vista Performance. Send your questions in ahead of time, then tune in for answers.

Learn a little, enjoy your daily computing life more.

Kate

Friday, September 12, 2008 7:21:46 PM (Eastern Daylight Time, UTC-04:00)  #    
# Thursday, September 11, 2008

The Tech Ed Online folks have kicked off a Women in Technology page. They’re aggregating blogs, videos, news, profiles and more. Take a look around – I’ve added it to my favourites.

Kate

Thursday, September 11, 2008 10:23:01 AM (Eastern Daylight Time, UTC-04:00)  #    
# Wednesday, September 10, 2008

Take a look at this map from Jeff LaPorte:

I wonder if this shows some sort of era-of-adoption effect, where folks in the US had widespread Internet access so they got started with AIM and never switched, then Canada and Australia picked up Messenger, and other places see a popularity of even more recent clients? Or perhaps it’s an artefact involving what kind of people use a messenging-interop solution? Whatever the mechanism, I’m a typical Canadian I guess since I use Messenger.

Kate

Wednesday, September 10, 2008 10:19:43 AM (Eastern Daylight Time, UTC-04:00)  #    
# Tuesday, September 09, 2008

Whenever an application blows up and offers to send information to Microsoft, please please say yes. On Vista it’s described as “checking for a solution” to make it more obvious what’s in it for you.

Sometimes, when you send this information to the giant Windows Error Reporting mother ship, you get a response that your blowup was caused by a known problem, and a link you can click for more information. That doesn’t happen to me very often, which I guess means I am among the first to find problems in shipping software. But that doesn’t mean you can’t benefit from the fix when the developers finally get around to acting on the reports they get from the WinQual program. Here is something you should do every month or so if you can remember.

First, bring up Problem Reports and Solutions. It’s on the control panel, or just click Start and type Problem, then press enter. You’ll see something like this:

Click View Problem History on the side. You will see a list of stuff that has blown up on your computer over the months.

Interesting, isn’t it? Click the Select all box at the top, and also Check Again For Solutions to Other Problems. Now click the Check for Solutions button. It will go and have a think:

It might also ask you if it can send extra info for some blowups, I always say yes. In for a penny in for a pound eh?

Then, the cool part. New solutions!

Click a link and you’ll get some more info with a link straight to the page that lets you get the update or latest version or whatever that specifically fixes the problem you had on your computer.

You can clear your problem history, but I am not sure why you would. You never know when a fix will show up for a problem you already had.

Kate

Tuesday, September 09, 2008 10:14:33 AM (Eastern Daylight Time, UTC-04:00)  #    
# Monday, September 08, 2008

Check out http://www.easyduplicatefinder.com/  - it has tracked down all the identical demos, powerpoints etc all over my C drive in quite a short time. I haven’t let it do the deleting yet, but the finding is worth a lot to me (I can delete for myself once they’re found.) Three gig of duplicates and that’s without looking on the networked shares where I store things when I’m done!

Kate

Monday, September 08, 2008 10:05:35 AM (Eastern Daylight Time, UTC-04:00)  #    
# Sunday, September 07, 2008

The guys call me a regular now, and I suppose I am. Here’s another hour of rambling and fun covering Vista (especially the Vista Bridge) the Vista things you’re not allowed to implement in managed code, C++, the MFC update, concurrency, and whatever else popped into my head while we were talking.

KateP>

Sunday, September 07, 2008 10:03:39 AM (Eastern Daylight Time, UTC-04:00)  #    
# Saturday, September 06, 2008

Imagine you have a bug that happens only in production. You connect to the production server and do a whole pile of exploring, and now you think you know what you need to tweak on your dev box to reproduce the problem and get started on fixing it. Or perhaps you are half way through figuring something out on your own machine and you need to hand over to another developer. Maybe you just want to switch to your laptop because you’re leaving the office. There are many reasons why you might want to copy breakpoints between computers. As you may know, they are kept in a .SUO file (Solution User Options I believe) in your solution folder.

But heavens above, do not try to copy that file from one machine to another! As John Robbins says:

The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!"

So John took care of this with his own add-in. You can save a set of breakpoints into a little file. You can then move the file between machines and use it to set all those same breakpoints on another machine. Or, probably even more fun, you can set aside the 20-some breakpoints, tracepoints, conditionals and so on that you painstakingly set up for bug A, save them and then clear them all, set different ones for the drop-everything-urgent bug B, and then when B is fixed you can get all your old breakpoints back and return to working on A. John is giving the add-in away, it works for both native and managed code, so go on, get it now.

Kate

Saturday, September 06, 2008 10:01:09 AM (Eastern Daylight Time, UTC-04:00)  #