Category Archives: Rants

Being a Good Windows Citizen

1
Filed under Installations, Rants, VB Feng Shui

I’m constantly amazed by some of the goofy things that application installations do to my system without even giving me the option.

Obviously, there’s the whole spyware/adware problem, but that’s just blatant.

There’s an entirely other, more subtle, level to the problem, where applications do little things that are difficult to undo, are annoying and that you aren’t given the option of not “doing” in the first place.

Here’s one example. Now, I like the CodeJock products, and I’m not really picking on them here, it’s just that they give me a good example:

image

This is the “Right Click – New” menu that you get from Explorer when you right click in a folder and select “New”.

Now, I’m a pretty busy developer, and I like a nice shortcut just as much as the next guy, but honestly, I can’t imagine EVER creating so many “Command Bars Designer Documents” that I’d want an entry for it on my New Items menu like this. As you can see, there’s already enough junk on this menu. I wonder how many people out there create a new contact, bitmap image or briefcase so regularly that it belongs on this menu. Hell, I’ve always created new Word docs by opening Word, starting my document and then “File-Save”-ing them wherever, never by the “New Office Word Document” menu, but then, maybe that’s just me.

A few others:

  • Unrequested shortcuts on the QuickLaunch space or the Desktop.
  • Unrequested Tray Icons.
  • Adding Vista Sidebar gadgets without permission.
  • Stealing file extension associations without asking and not restoring them on uninstall.

Any other bits of application rudeness out there anyone has run into?

My Entries on the List of Things to Hate about VB.Net

0
Filed under Rants, VB Feng Shui

First, I should say I’m a pretty ardent supporter of VB, even VB.net. Heck, that should be obvious from the name of this blog<g>

But, as I’m getting more and more into the “.net” of VB, I’m finding more and more things to dislike about it.

There’s plenty already written on this subject and maybe I’m a tad late to the party, but I haven’t seen these particular things mentioned before, so here’s my additions to the topic.

  • Sluggish IDE. Good god. I’ve got a dual core Core2 rig with ultrafast video and 4gb of ram, and the VS2008 IDE feels like trudging through a Valdez-soaked beach compared to working with VB6. I understand this isn’t specifically a VB problem. The IDE applies to all .NET languages. But that doesn’t change the fact that if you program in VB, you use the IDE, and it’s a dog.
  • Intellisense. I like Intellisense, the concept, but there’s just something about the VB.NET implementation that is so much more “in the way” that VB6’s. It feels a bit like that brother-in-law that you can’t get off the couch soon enough…
  • MDI style IDE. While there are definitely some improvements to the UI of the IDE, and just maybe I’m a relic, but I MUCH prefer the VB6 (and before) “SDI” floating windows style IDE to this monolithic, MDI style environment. To make good use of it, you have to maximize it on-screen, which hides everything else onscreen. Granted, a nice dual or triple monitor setup minimizes that impact, but still, I just find it much more cumbersome and “in the way” than the old environment.
  • Uninitialized strings variables. This one just floors me. Take this code:
        dim s as string
        debug.print len(s)
        debug.print s.length
    The len(s) line works like you’d expect (you get 0), but the s.length line fails with an error! What the hell? An uninitialized object? This is like a car manufacturer coming out with the new year model and swapping the gas and brake pedals. I don’t care whether they told me about it before or not, it’s just plain stupid. Why on earth have two functions that do exactly the same thing but one works as any longtime VB programmer would expect and one does not? And no, “That’s just the CLR/it’s necessary for C#/Blah Blah” just doesn’t cut it.

As I read through many of the posts, I have to admit I’ve started to wonder myself as to whether this is all some low-level ultra-subtle manipulations on the part of MS to nudge people further and further away from VB. Yes, it starts to sound like conspiracy theory, but surely, all this couldn’t be completely unintentional, could it?

Even so, there are ways around some of this. And I still much prefer VB, the language, to anything even resembling C and it’s ilk.

Still, if no one complains, things won’t change (or they’ll get worse<sigh>).

Fixing System.String

1
Filed under .NET, Languages, Rants, VB Feng Shui

String manipulation is a very different beast in VB.NET than in VB6. In fact, I’d wager that it’s the one area that trips up programmers new to VB.NET more than any other aspect of the language.

I’ve talked about some annoying aspects of System.String before, but this go round, I’m going to concentrate on shared methods.

Shared Methods are methods that are invoked via the class type itself, and not via an instance of the class.

For instance, with strings, you have a nicely named IsNullOrEmpty  function that you’d expect would return a true/false indicating whether the string in question is null or empty. Unfortunately, you’d be only half right.

Bring up the Object browser and find the String class, then highlight the IsNullOrEmpty method and you’ll see this:

image

Notice the Shared keyword. That indicates that this method IS NOT an instance method, thus you can’t invoke it via a specific instance of a string; rather, you must invoke it via the String class directly.

So, you can’t do this:

Dim s as string
If s.IsNullOrEmpty Then

But you can do this:

Dim s as string
If String.IsNullOrEmpty(s) Then

Now, it makes perfect sense, from a purely technical perspective, that invoking an instance method on an uninitialized object wouldn’t work anyway, so a method like IsNullOrEmpty wouldn’t make sense to be an instance method, since attempting to invoke it via a variable that hadn’t actually already been initialized would result in an “Object not Set” error.

However, this is VB, not some ivory tower exercise in theoretical language design. If I’m going to invoke a method like IsNullOrEmpty, I’m expect to be able to do so against an instance. Having to invoke it via the String class is just so utterly unintuitive, it defies all reason.

Oddly, the very argument that I note above in favor of using a shared method for IsNullOrEmpty is violated by another string property, Length. Here’s a property that is definitely an instance property, but causes VB code to fail (with the Object Not Set error) when invoked on a variable that hasn’t actually been set to value yet.

Is this just an arbitrary oversight, a design flaw, or an intentional “feature” of the language? I can’t answer that.

But, realistically speaking, I can say that it’s utterly frustrating to have elements of a language, such as these, behave so drastically different from one version to another. It doesn’t matter that the syntax is different (x.Length vs Len(x), for instance), there is an expectation there that simply is no longer met and does nothing but confuse.

Fortunately, with VB 2008, there is a relatively trivial way to correct these problems, and likely a host of other similar issues.

It’s called “extension methods”.

To create an IsNullOrEmpty that works like any reasonable person would expect it too, just put this in a Utility module somewhere in your project:

Imports System.Runtime.CompilerServices

Module StringExtensions

    ''' <summary>
    ''' Returns True if the current string instance is nothing or a null string
    ''' </summary>
    ''' <param name="aString"></param>
    ''' <returns></returns>
    <extension ()> _
    Public Function IsNullOrEmpty(ByVal aString As String) As Boolean
        Return String.IsNullOrEmpty(aString)
    End Function
End Module

The Imports System.Runtime.CompilerServices is only used during compilation. You can actually continue to target the .NET runtime v2.0, even if you use this code (however, you still have to compile the code from VS2008, it won’t work in VS2005).

You tag the new version of IsNullOrEmpty with the <extension()> attribute to  mark it as an extension method.

The first parameter of an extension method is required and is an argument of the type of class that you’re extending, in this case the String class.

You can have additional arguments if necessary, but you don’t need any for this method.

This trick takes advantage of the fact that even though the String class already has a method named IsNullOrEmpty, the function signature is not the same as this one (since ours has the implicit first argument). This is effectively an overload and it allows VB to know to call the new method if invoked against an instance, and the old one if invoked against the String class directly (which is exactly what’s being done within the method itself!).

There are several other “shared” methods on the string class that can similarly be extended to more intuitive instance methods in this way, for instance:

  • Compare
  • Concat
  • Format
  • Join

Length could also be added to this list but you can’t quite treat it the same, since it’s a property, and the Extension attribute can’t be applied to properties.

Finally, extension methods can be unbelievably useful for associating functionality with specific classes that you can’t extend in any other way, but, as always, you need to be careful with how much you extend a  class.

For example, it might be tempting to extend the String class with all sorts of path/file/folder manipulation and parsing logic, so that you could do something like this:

dim s as string = "c:\myFolder"
debug.print s.DriveLetter

but doing so could quickly clutter the String object and Intellisense.

As usual with these sorts of techniques, use judiciously.

One Big Control or Lots of Little Ones (redux)

3
Filed under .NET, ASP, Rants, VB Feng Shui

Some time ago, (or here in the wonderfully virtual web world), I questioned the whole aspect of all this pile of controls in ASP.NET. Of course, you’ve got the grids and listviews, and you also have all the radio buttons, checkboxes. But then you’ve got a separate validator for each kind of validation you want to use, and even validators to let you combine other validators in “AND” and “OR” logical relations.

My thoughts were “Jeez. this is madness.”

Wouldn’t a single control that you could adapt to different display behaviors, validation rules etc be much easier to work with and create a more maintainable solution?

Well, apparently someone at Microsoft had the same bright idea, at least with the new ListView control in ASP.NET 3.5.

Take a read of Fritz Onion’s article in the latest MSDN magazine.

He describes the new ListView as a control that can “literally replace all other databinding controls in ASP.NET. That’s right. Every last one.”

Now, if they’d do the same for that validation nonsense, we might be getting somewhere!

Quicken Online?

1
Filed under Misc, Rants, Security

I can see doing a lot of things “online”.

Email? GMail is pretty dang slick, with a spam filter that’s second to none.

Stock Portfolio and watchlists? Sure.

Craig’s List Searches? Right there on my homepage.

Word Processing? Spreadsheets? Hmmm. Google apps is definitely interesting, although I tend to want to keep my files close at hand.

Personal finance information? Huhwhaaaa?

Call me old fashioned, but the thought of putting access info to my entire checkbook/credit card/bank account/investment accounts online just seems a little, uh, risky?

Hell, it’s probably all already out there, but is it really a good idea to put concentrate all that in one place, online, in the ether on someone else’s server?

Hmm, looks like somebody already has. But wait, this is great. Check out the bold restriction in their terms of use. Why oh why would anyone put private info on some company’s server when said company says up front not to put financial info there. Damn, I hope they have a good E&O policy!

I suppose SalesForce.com asks their customers to do it every day (after all, isn’t your company’s client list a bit like your ledger?) and nobody has much of a problem with it.

So maybe I am old fashioned.

Then I saw this (from the QuickenOnline.com website):

Build your whole financial picture for up to 5 years.
Most banks keep your online data for only 60 to 90 days. 
With Quicken Online, you build your whole financial picture 
from the day you start. We keep active customer's data for up to 5 years.

5 whole years! How generous! And I guess after five years, all that data would be useless to me?

Um. I don’t think so.

Guess I’ll stick to the tried and true for now.

A Grousing About Properties in .NET

0
Filed under .NET, Rants, VB Feng Shui

I’ve started playing more and more with .NET lately. There’s a lot to like, a lot to dislike, and a few things that left me scratching my head.

One is this new fascination with moving regional (or class scoped variables) up to right on top of the properties that are wrapping them.

You’ve no doubt seen the pattern.

In old school VB6, you’d have something like this:

    {top of class}
    Private _MyPropVar As Boolean

    {lots of code here}

    Public Property Get MyProp() As Boolean
        Return _MyPropVar
    End Get

    Public Property Let MyProp(Byval NewValue as Boolean)
       _MyPropVar = value
    End Set
    {code continues}

And in the New Order, you have this:

    {other code}

    Private Shared _MyPropVar As Boolean = True
    Public Shared Property MyProp() As Boolean
        Get
            Return _MyPropVar
        End Get
        Set(ByVal value As Boolean)
            _MyPropVar = value
        End Set
    End Property

    {code continues}

Now, the pundits out there claim that the ability to move the definition of the variable that stores the property value down in the code to where the property is actually defined is a good thing.

And it very well might be.

But if that variable is used elsewhere in the class (it is, after all, visible to the entire class), then it makes more sense to me for it to be grouped with other such class scoped variables at the top of the class, and not buried within the class.

What’s most frustrating about this, though, is that the language designers had the perfect opportunity to solve this problem elegantly, and didn’t.

The simple introduction of a property scope would have done the trick. Then for those variables that are ONLY used to track the contents of a property, you’d have this (note the _MyPropVar definition has moved to INSIDE the property declaration):

    {other code}

    Public Shared Property MyProp() As Boolean
        Private _MyPropVar As Boolean = True
        Get
            Return _MyPropVar
        End Get
        Set(ByVal value As Boolean)
            _MyPropVar = value
        End Set
    End Property

    {code continues}

Now there may be significant ramifications involved that prevented this change, and I’m certainly no expert at compiler design or implementation (though I have implemented a pseudo-code compiler scripting language used in a commercial product).

But this just doesn’t seem like all that big a deal to have implemented and would have cleanly resolved where to put variables of both persuasions (ie those that are used by ONLY a single property, and those that are truly class scoped and used my multiple properties/methods).

Personally, I think this was a bit of a “good enough” decision.

Practically, I think I’ll stick with locating truly class-scoped variables at the top of the class, and ONLY bury variables that really are only accessed by a single method/property.

Public Interfaces

0
Filed under Rants, Software Architecture, VB Feng Shui

image I’m guessing that the vast majority of VB apps (VB6, or .NET), have no public interface. After all, VB is the prototyping language, not an actual project development language, right? </sarcasm>

Well, if you do eventually find yourself in need of exposing a public interface from your application, what’s the right way to do it?

First, a definition, though.

By public interface, I’m talking about some manner of exposing functionality within your application to the outside world. What you do with your BAS files, and private CLS files, not to mention FRM’s, or the all-encompassing  VB.NET *.VB file is your own business. But what the world sees, or, more appropriately, has to deal with, is another matter altogether.

There’s a pile o’ ways to expose functionality from an app, especially a VB app.

First, a few old school methods….

  • DDE – Yeah, it’s still alive. Want proof? Just boot up a copy of Vista, load REGEDIT and search for DDEEXEC in the HKCR hive. But seriously, you don’t want to go there.
  • Windows Messages – SendMessage/PostMessage. They’re not just for subclassing and peeping toms. DDE and even COM relies on the Window Messaging subsystem to work. Your apps can leverage it too. But really, that’s a whole lot of pain for not a lot of gain, so why bother?
  • DLL Entry Points – There are several tools out there that make exposing DLL entry points from a VB application relatively easy to do. In some cases, this is how you have to expose functionality (as in when some other app only makes calls to DLL entry points, and you want that app to talk to yours). But using this technique to expose your own functionality to the world just seems so, well, reagan-omic.

And the more common techniques….

  • COM – The classic VB PUBLIC class. All you gotta do is change your class’s interface type to PUBLICNOTCREATABLE, MULTIUSE, or GLOBALMULTIUSE and biff boom pow! Anyone can use your class, right?
  • .NET Assemblies – Same as COM, but shinier

OK, COM (or .NET assemblies) it is (I’m going to consider the two the same for now, what sacrilege!)

So how do you do it?

There’s piles of books on the mechanics of the task, so I’m not going there. Just look at Kurata’s Doing Objects in Visual Basic 2005 or Dan Appleman’s various books on ActiveX techniques for those kinds of details.

What I’m talking about is which interface design is most appropriate.

Kinds of Interfaces

Generally, I’ve seen these designs gather into 3 camps:

  • The massive wad of hierarchically related objects. This is the Outlook, Word or Excel object models.
  • The single public class containing all the functions you could ever want. Not terribly common; I see it most is 3’rd party utility libraries.
  • And finally, the single class with a single (or at most very limited set of) functions that serve as a “command line” of sorts where you might pass in a parameter that is the “operation” and that additional parameters that are the “arguments for the operation”. The GroupWise API is a great example of this.

The Massive Hierarchical Wad

Pros

  • Easiest to program against. Intellisense, separate objects, etc speed working with your model.

Cons

  • Hardest to keep compatible. Even minor changes from one version to the next of your application can render it incompatible with previous versions of your application, causing loads of headaches for your users.

The Single Class

Pros

  • Relatively easy to program against. Intellisense will help. So does consistent naming of all those methods and properties.
  • Works well for relatively minor amounts of exposed functionality.

Cons

  • Generally considered bad practice.
  • Suffers from compatibility headaches much like the Massive Wad.

The Command Line Class

Pros

  • Essentially immune from direct interface compatibility issues, since the lone interface is flexible enough initially to never have to be changed.

Cons

  • More difficult to code against. Intellisense only helps with the command line function itself, not with each of the commands that can be sent.
  • Moves compatibility issues to the user. If new functions are introduced, it’s the users responsibility to test for the version of the application and react appropriately.

So, what’s the final word?

As usual, there’s really no right answer.

Personally, I tend to stay away from the “Single Class”, simply because it has all the difficulties associated with the Massive Wad, and none of the immunity of the Command Line Class; the worst of both worlds.

The Command Line Class is most useful when your exposed function points number in the 10-100’s. Any more than that, and it starts to become unwieldy, though it’s still perfectly workable.

The Massive Wad is the most traditional, most familiar style of public interface to those who’ve likely used public interfaces of other systems. That’s not to say it’s the best option, just that’s it’s the most typical.

How about it? What kinds of public interfaces have you built and put out there? Is there a style I’ve missed. Maybe something better than any of these?

So I Printed Out all the Internets Yesterday….

1
Filed under EMail, Rants

I was reading the latest ComputerWorld (Oct 29) and came across one of the best quotes I’ve seen in a while.

I’m not a huge fan of Grady Booch, but he has had quite the impact on IT. I just can’t stand UML.

At any rate, there’s an interview with him in this issue and at the end, he’s asked what has surprised him most in the last decade.

He responded:

“I haven’t seen any revolutions.Heck, I had my first email address in 1979. There was a printed document with everyone’s email address [in the world].”

Man, oh man, that’d be a sweet piece of tech memorabilia to hang on the wall.

Does that make me a geek<g>

The USS Millennium Falcon

0
Filed under Misc, Rants

NASA has a nifty little “picture of the day” feature that you can add to your Google Homepage.

A picture that came up just yesterday shows the shuttle lifting off against a gray sky. Here’s a snippet (from http://www.nasa.gov/multimedia/imagegallery/image_feature_940.html):

image 

But the thing that struck me about this is how much our space program is beginning to resemble the Millennium Falcon.

image 

The rusty tanks, the patchy paintwork, using a stapler for repairs. It’s starting to look like the shuttles may have made the Kessel Run a few times themselves.

 image

(Detail from above)

Compare to this 1983 picture from the Wikipedia entry:

image

And this about 20 months before the first shuttle launch (again from Wikipedia):

image

Clean and sparkly

Cripes, it’s 2007. Shouldn’t we be flying something like this:

image

from www.starwars.com

and not this:

image

from http://www.art.net/kiyotei/blogs

How NOT to set up an issue tracking email service

1
Filed under Rants

Here’s a snippet from a recent Microsoft email I received when I opened a ticket with them through the MSDN support channel.

******* The following is an email for a support case from Microsoft Corp.
******* DO NOT REPLY TO THIS MESSAGE--your email will not be added to
******* the case if you do.  Instead, FORWARD your response to the
******* email address COMPMAIL@MICROSOFT.COM and place your text after
******* the keyword 'MESSAGE:'.  Also, delete all other text above
******* and below the keywords 'CASE_ID_NUM: SRnnn' and 'MESSAGE:'
******* to ensure proper delivery of your email.  Thank you.

Now, I’m pretty technical, but any support email conversation that you have to read several times over in order to even reply to is, uh, shall I say, unfriendly. 

And the wording, “DO NOT REPLY TO THIS MESSAGE…”, and “Instead, FORWARD…”. Wow, the antithesis of friendly.

What’s worse, when I did exactly as was indicated, the email failed to go through with my attachment. I ended up, get this, having to send a reply to the very FROM address that the snippet above indicated NOT to reply to!

Now, I’m not pointing fingers at the techs themselves here; I doubt the guy that clicked the button to send this email was actually responsible for the content of this header.

But seriously, someone at Microsoft needs to take a lesson or three in email etiquette.