The VS 2008 VB will support nullable types.

Simply put, a nullable type is a standard type, like, say, integer or string that can ALSO contain a null.

This can become very important in database work, because a null value in a field means that no value has been assigned to that field vs a common case where you might use 0 in a numeric field to indicate no value, or you might use a null string (ie a string with no length) in a string field.

Obviously, using 0 to indicate no value works much of the time, but, there often comes a point when you actually do need to use a 0 value for that field.  There's a number of other, more arcane reasons that using one of the values from the range of possible values of a type to indicate null is usually not a good idea.

Hence, nullable types. With a nullable type, I can have an integer variable that can be a 31bit positive or negative number, or 0, and STILL have yet another "state" of that variable that indicates it's null.

This will likely be incredibly handy for many many uses when working with database data.

But the syntax?

Dim a As Integer?

or

Dim a? As Integer

No, I'm not making that up.

What the hell? A question mark?

Why not just:

Dim a As Nullable Integer

I find this to be an unbelievably hypocritical decision given the almost overwhelming philosophical rants delivered by Microsoft about not using the traditional VB type specifier characters in .NET anymore (you know, $ for strings, % for integers, those bad boys). Heck, check page 42 of "Framework Design Guidelines" by Krzysztof Cwalina and Brad Abrams of Microsoft:

DO NOT use Hungarian notation (their bold, not mine)

Now, to be fair, the authors in this particular instance are discussing publicly available interfaces, but I've seen the same directive applied to internal coding as well. So, we're not suppose to use hungarian, and we're not supposed to use type characters, so we're left to simply scan the code to information about how a variable is used or what it likely contains. Jeez. How convenient.

Not sure if it's working entirely yet, but it appears to at least be serving pages.

Let me know if you notice anything amiss.

I haven't been coding too much in ASP.NET, and it seems like every time I sit down to do something in it, things have gone fubar in some random, unexplained way.

The latest example. I went to start a web app that I'd debugged plenty of times before and ended up with

Unable to start debugging on the web server. An authentication error occurred while communicating with the Server

Ok, start googling. 

I tried everything I could find to no avail.

Then I happened on Mike Volodarsky's Server Side and this article.

I'd run smack into a full-on bug in VS2005, and not a small one. Mike's post details why all of the alternatives have their drawbacks and then he presents his "Debug Assistant" that works around the bug and allows you to start in F5 debug mode anyway.

And even better, he updated the post with details about KB article 937523 that describes a hotfix to resolve this problem.

Unfortunately, the hotfix is one of those that MS insists you call them to obtain, but Mike makes the link available. It's here.

Anyway, downloaded the hotfix, applied it, and I didn't even have to reboot. Debugging works great (ie like it should have in the first place) now.

A big thanks to Mike, for posting about this bit of VS nastiness.

Now, it's ~3hours later. What was it I sat down to take a look at in my ASP app again?

Ages ago, I happened onto Bruce McKinney's HardCore VB and the Win.TLB file that he created and I was hooked.

Ever since, I've been a big fan of using typelibs with VB6. They're relatively compact, support help, work nicely with Intellisense, and, most importantly, any elements of a typelib that your project doesn't use, don't get compiled into you project, unlike standard VB DECLARE statements.

Furthermore, typelibs provide just about the ONLY way to access certain COM interfaces that are normally declared with attributes that make them unusable by VB.

For examples of that, check out Edanmo's page, or the VBAccelerator stuff.

I've been using Matt Curland's Excellent PowerVB Typelib editor to edit, extend, and generally hack and bash the original win.tlb (I generally don't use unicode much explicitly, so I haven't kept the WINU.TLB unicode variant up to date, unfortunately). Note, though that you have to buy the book to get the editor. If you do this much, the editor alone is worth it, but the book is truly the best books on low level VB6 out there.

Doing things the Right Way

However, I really wanted to get this thing back into shape, and I felt like the best way to do that was to get it BACK into IDL format, and then use the MIDL compiler on it.

You'd think that doing so would be, basically:

1. Load the TLB into OLEVIEW
2. Export the whole thing as an IDL file.
3. Edit the IDL with a text editor
4. Run MIDL on it to recompile the WIN.TLB and presto! Nice new, clean tlb file.

Sigh. Is anything ever that simple?

Problems, Problems

First, OLEVIEW exports things in completely the wrong order (I'm not exactly sure what it uses to order things other than just the defined order in the TLB). As a result, I got tons of "symbol not defined" errors when I compiled, because a call referenced a structure that was defined later in the IDL, and didn't have forward declaration.

Shuffling LOTS of typedefs around, I resolved all that, only to end up with tons of MIDL2022 "illegal or missing value for entry attribute", as well as MIDL2270 "duplicate UUID" errors.

The duplicate UUID errors I fully understand, even though I really don't like it. Basically, the TLB "redefines" a number of internal COM interfaces to make them usable by VB, for instance IEnumString.

However, MIDL doesn't allow you to redefine an interface that already exists, and that particular interface does already exist.

In that case, commonly, you just rename your new definition to, say, IVBEnumString.

And with mktyplib and Matt's TLB editor, that's no problem. But MIDL see's the old IEnumString (defined in the automatically INCLUDEd OBJIDL.IDL) and the new IVBEnumString, notices that they have the same UUID (which they must) and throws that MIDL2270 Duplicate UUID error.

Bruce resolved this by actually copying the OAIDL.IDL, OBJIDL.IDL, UNKNWN.IDL and WTYPES.IDL from the Visual Studio 6 Include dir right into his TLB project, and modified them as necessary. It works because of the MIDL search rules, but I REALLY didn't want to continue mucking with the MS IDL files. I'd much rather just redefine those that I need to redefine and be done with it. Just seems like a safer alternative.

Ok, fine, so I go back to mktyplib and move on.

Not so fast, young Skywalker!

mktyplib is an older tool (read, unsupported, not maintained, and generally considered just that much bit junk now). And sure enough, a very common element in my type lib, it doesn't support, namely non-variant optional parameters.

I have a line of ODL (mktyplib's prefered input file type) like:

      HRESULT _stdcall Commit([in, optional, defaultvalue(0)] STGC grfCommitFlags);

And it has no idea how to handle that OPTIONAL and I have too many of these to bother counting them all (ok, not really, there's 64).

I really don't want to have to make all those method parms suddenly "required" when they're not.

The Cycle of Irritation

So, here I am, hours later, and back where I started.

I'm going to continue using the PowerVB editor to update the WIN.TLB file.

And just to recap, my version started from Bruce McKinney's ANSI version, generally targeted at VB5, then pulls in LOTS of additional COM interfaces, ala Edanmo, VBAccelerator, and others, corrects some issues with certain calls that VB5 had no issues with but VB6 didn't like, throws in lots of new ENUMS for parameters of functions instead of just blind LONGs where you get no Intellisense, and rounds things out with a little bit more help text for some methods (though that's still pretty spotty).

One nasty habit of TypeLibs

One thing to be very careful of if you do start working with typelibs, is to make sure that any API function you decide to pull in and actually use will exist on the target machine.

These days, that's not particularly hard. Win2k through Vista have changed very little as far as typical low level API's are concerned.

At one point, my apps were running on everything from Win95 through XP, and there were definitely issues with commonly used functions existing under Win2k or XP that had no equivalent under 95 or 98. In those few cases, I just resorted to a standard VB declare and then error trapped the call. If the function wasn't available, you'd get an error, trap it and deal with it.

However, if that same function was defined in a typelib, the app loaded will validate all implicitly linked libs and try to resolve them all at load time. If it failed for ANY function, the app won't load at all, and all this happens before any of you VB code has a chance to do anything about it.

I recently blogged about showing your ICQ status on a webpage and I get this in the mail....

AIM now has a service called WIMZI that allows you to embed a little script on a page and lets visitors to a site chat you up without getting your AIM ID, etc.

Very interesting. Even better than the status indicator because a visitor can start a chat right there on the site. A bit like those "Chat with a support rep" services, but it's effectively free.

I wonder if that will end up having an impact of any sort on the paid offerings. I'm guessing they support a bit more accountability, plus some amount reporting (number of chat requests answered per rep, that sort of thing).

I'll have to try it out here soon.

I've been delving into ASP.NET programming lately and one thing that immediately struck me as odd is just how many controls end up on an ASP page.

A typical data entry page consists of, generally, lots of labels and textboxes, a few option buttons or check boxes, even fewer combo boxes and list boxes, a grid maybe, and few buttons (buttons, links, whatever they happen to look like).

Granted, depending on the application, you may have a few particular screens that are more complicated (say, a scheduling screen), but by and large, for general data input, that about sums it up.

But when I look at what's involved in ASP.NET to make that happen, it's almost mind boggling.

Of course, you have a label control for a particular field, you have the field itself, but then you have separate validator controls for each kind of validation you might want to perform. Add in tables to get things to line up nicely

To me, it seems much more logical to have one "data input" control, that can handle all (or rather the most common) data entry tasks via properties.

Want a caption above the input box, rather than to the left of it; set a property. Want the text to be validated a alpha numeric, but only including A-F, and it must be > 4 chars, less than 10, blah blah; set a property (or two). What this field to be a choice between True/False; set a property to make it a radio button group, a list, or a drop down combo box.

Ages ago, there was a UI package called SmartUI. Looks like it's now sold by Xceed. No idea whether it's any good now. It was ok back then, although it had it's share of issues. But I always thought the idea was right. One control that could do all sorts of the most common data input type tasks, just by dropping it on a form and setting a few properties.

I completely understand the idea of "modularizing" functionality and the ASP control model definitely does that.

So my question is, is that the best way?

All those controls eventually just render HTML anyway, so is there a penalty for one big control vs lots of little ones rendering that html?

Does it make the page easier for the user to work with?

Do separate little controls make it easier for the developer?

Microsoft used to say that INI files were the absolute best way to store your application settings. Then it became the registry, and INI files were passe. Now, it's back to INI files...albeit with a lot more tag stuff, funny angle brackets and often terrible formatting...oh, right, I mean XML files.

My point is, I'm not one to just accept Microsoft's take on a topic, no matter how much framework they've thrown at it. 

And I'm wondering if their control model might be another one of those reasons to break with the pack.

Paul Moller (the aircar guy) has finally made at least one of his designs available for sale, the Volantor.

Ok, it's a tad goofy looking, and at 125k$ plus, it's bit out of, oh, damn near everyone's, price range, but still, it is for sale.

Personally, I'm waiting to see the first M400 flying around.

The amazing thing to me is that this guy has been working on this idea since the 60's, developing all sorts of technology in the interim to fund it (and contribute to it).

Dr. Moller, keep it up!

Years ago, I used SideKick as my PIM, then I ran into Tornado Notes for DOS, which became InfoSelect for DOS, which got ported to Windows 3.1, and which is, in it's latest incarnation, still my PIM of choice.

But during my search, I kept coming back to a very interesting little app called TheBrain.

A static picture doesn't do it justice, you need to navigate around in it to get the full effect. It's gaming meets info management if ever I've seen it.

I never could see the benefit of that kind of arrangement for managing your personal information because, for my personal info, I already know how things are connected, I just can't remember the details.

But for navigating information that you don't know much if anything about in the first place... Now that's where this kind of thing can shine.

And back in the present, I just stumbled onto The Visual Thesaurus that does just that. It's a pretty nifty way to explorer around seeing relationships to words visually. I could definitely see children learning lots of new words by navigating through similar words they already know. Plus, its got that "video game" flare that screams Play With Me!

Or how about a visual code navigator, for developers new to a large project. Browsing through a project using that metaphor could be very illuminating, very quickly.

I'm not sure that Visual Thesaurus will actually make it or not. I don't see many people paying even their low $2.95 "subscription" for it. But the idea, and more importantly, where it's been executed, seems like a good one to me.

Can I get that in an OCX?

I just ran into an ad for Dell stuff on the Wired website.

Normally, I don't click ads, but I like Dell widescreen lcd monitors, so I had to check it out.

Dell is now offering a 30" Widescreen monitor! (I just wish one of their pictures put a soda can in for scale reference)

Its the 3007 WFP-HC, and, if it's even remotely as good as the 2405FPW or the 2007FPW (I have one of each of these), it's gonna be tough to resist clicking that "order now" button.

Check this blurb out from the site:

Note: For the best viewing experience, your PC must have a dual-link DVI-D graphics card that supports 2560 x 1600 resolution.

2560x1600 resolution. In the immortal words of Keanu Reeves, Whoa.

That's a pile of pixels to be pushing around.

One of the guys I worked with asked me how I could program in white text on a black background. Put this baby on your desk, load up VS2005 and maximize it, then try staring at ~400 square inches of FFFFFF about 24" from your face for 8+ hours a day. The 24" Dell I have can light up my office all by itself with a full white screen. 

You could use this thing to signal aircraft.

Scott Hanselman recently did a very nice series of posts about building his "Ultimate Developer Rig", a quad core, dual PCIE video card monster machine, that certainly has some impressive specs to it.

That Scythe Cooler is particularly impressive:

Too bad he didn't totally geek out and put a plex window and some light tape in there... Too much?

Now, there are some that would say this is the "Ultimate Developer Rig":

(For the full specs, check it out here.)

But I gotta say, Scott's setup is pretty hardcore. In fact, it's almost eery the similarities between Scott's rig and the one I put together a little less than a year ago. I went with a dual core E6600 because, well, if the quad cores were even out at that time, they had to be too rich for my blood. I tried, hard, to justify the 1000$ for a E6700 Core 2 Duo Extreme at that point, but just couldn't do it.

Still, my rig gets right up there, scoring a 5.5 on the "Windows Experience" scale in Vista. If I was so bold as to delve into overclocking, I might even improve on that some. Maybe eventually.

Then, I stumbled upon Kevin Hammond's commentary on Scott's rig, and I have to say, I'm right there with Kevin.

I diverged from Scott's rig in much the same ways Kevin recommends, with a few minor deviations:

• Vista 64 just isn't ready from primetime, due to driver and utility support
• RAID 10 is hard to beat for resisting downtime
• I went originally with a Gigabyte GA 965P DS3 board, but then switched to an Intel D975XBX2 when I discovered the Gigabyte didn't do 4 drive RAIDs
• I used a Zalman cooler instead of the Scythe. I guess I'm partial to copper
• Scott damped the inside with foam. With that Antec case, I haven't noticed the need to. It's virtually silent once the fans initially power up.

About the RAID, George Ou wrote a pretty good article on half-stroking or quarter stroking a harddrive to improve its performance. No idea whether it has similar effects on a RAID. In other benchmark tests, George pretty much slays RAID 10, which I'm a fan of. I've lost a drive out of a RAID 10 setup, replaced it and was on my way with no downtime. But when I lost a drive out of a RAID 0, I was down for almost 3 weeks trying to get everything back and operational. And drive images are only good if almost everything else about the machine stays the same, which, in my case, didn't.

None the less, if you're looking to put together a wickedly fast machine for under 2 grand, and you want it to be so quiet, you NEED lights on the outside to tell it's on, I highly recommend reading through Scott's parts list.