Monthly Archives: June 2008

It’ll definitely sting the checkbook!

0
Filed under Hardware

Just stumbled across what has to be the hands-down coolest workstation yet.

It looks like a cross between the swiveling chair in the Millennium Falcon and the long abandoned gunner’s chair from “Alien”. It’s called the Emperor from NovelQuest.

image

That monitor arm thing? It actually electrically lifts those monitors out of the way to allow you in and out. Not sure how practical that is, since it’d require, what, a 20ft ceiling in your office.

No idea how much. It doesn’t go on sale till July ’08. But seriously. Wow.

Slow Vista Copying and Deleting

0
Filed under Uncategorized

image Like a lot of people out there, I’ve been bitten by the Vista “Slow Copy/Delete” bug many many times myself.

I finally decided I’d had enough today and when looking for a solution.

I came across a couple of posts discussing a hotfix available from Microsoft, but it’s apparently not that easy to get a hold of, and its a questionable fix at that.

Then I happened across a short post in a SlashDot discussion that mentioned turning off thumbnails in the Explorer view.

I’ve never heard of that one, so I gave it a quick shot.

First, open the Folder Options:

image

Then, just make sure the first option “Always Show Icons, never thumbnails” is checked:

image

Surprisingly, this does seem to a have a pretty dramatic effect on the copying and deleting processes, as well as noticeably speeding up the time it takes to get from a right-click to actually seeing the right click context menu in Explorer. It’s still not instant like it should be, but it’s better than before.

I’ll keep playing with it and post if I discover any other interesting bits about this seemingly easy workaround.

Line Numbers and VB.NET

7
Filed under .NET, Troubleshooting, VB Feng Shui

Line numbers have been around ever since the dawn of time in BASIC.

Remember this classic:

10 Print “Hello”

20 Goto 10

But what many people may not know is that line numbers still exist in VB.Net!

Yep, that’s right, you can write the above routine, as I show it, in VB.NET.

Well, with one exception. Line numbers in .NET are treated as full on labels, and labels must be followed by a colon. So you’d have this in .NET:

10: Print “Hello”

20: Goto 10

Now, before I start getting hate mail about GOTO’s and such, let me say that I’m only a fan of a GOTO in a few very controlled circumstances.

But GOTO’s are the point here. Way back in the Visual Basic (Pre .NET days), line numbers combined with the ERL function made for a surprisingly effective field debugging tool. If you line numbered your code before compiling, and used ERL appropriately during your error handling, you’d be able to precisely pinpoint the offending line of code very quickly and painlessly.

I’ve used that approach for years, and even wrote an article in VB Programmers journal at one point about a very extensive generic error handling facility.

Recently, I decided to look into updating that facility for VB.NET, and unfortunately have good and bad things to report.

First the good.

  • As I said before, VB.NET still supports line numbers and the ERL statement, as well as all the old favorites ON ERROR RESUME NEXT, ON ERROR GOTO, RESUME, and RESUME NEXT.
  • You can easily compile VB.NET projects from the command line, making it relatively trivial to create a simple batch file to line number your code, compile it, then clean up the line numbered version.
  • VB.NET supports a much more sophisticated StackTrace/StackFrame functionallity that would seem, at first glance to obviate the need for ERL entirely.

but now the bad…

  • The StackTrace/StackFrame functionality works fantastically, as long as you’re willing to ship the program debugging database (PDB files) that are generated when you compile your project.
  • Worse still, you can’t use the old style ON ERROR GOTO, in the same method as the new style TRY CATCH FINALLY exception handling.

image

  • And finally, the ultimate bit of nastiness. While trapping an error with the old style ON ERROR GOTO will generate a standard exception (See the Err.GetException method), trapping an exception with structured exception handling (also known as SEH, or TRY CATCH), does not affect the ERR object at all, specifically, throwing an error in a TRY block will not set the ERL value, even if the code is line numbered.

image

So what’s the end result of all this?

Basically, do not even bother with ON ERROR GOTO style error handling in VB.Net. Even though it would appear to be supported, and even though retrieving the line number of the failing code isn’t possible without shipping your PDB, the fact that line numbers aren’t reported in code using SEH makes them pretty much useless. SEH is quite useful in many situations, so you wouldn’t want to not use it solely because of this.

But that doesn’t address two very real issues.

  1. Line numbers in stack traces are an incredibly useful debugging tool
  2. You don’t want to distribute your PDBs just to get line numbered stack traces if at all possible.

More to ponder…

Internationalizing Applications

0
Filed under Languages, VB Feng Shui

image A recently posted article on CodeProject had this to say about Visual Studio’s support for multi-lingual applications:

Conclusion: Visual Studio .NET does not offer any multilanguage support which is worth thinking about it.
You will only waste your time with Microsoft’s approach!

Check the whole article/project out here.

I can’t verify the author’s credentials that would justify such a claim, but from the sound of it, he did at least start down the MS sanctioned path, and I have to agree with him.

Way back in the dark ages, pre-internet, around 1990 or so, I was managing development of a CRM system (customer relationship management software).

We’d picked up some resellers oversees and needed to get the product internationalized. This was really at the very beginning of Windows even (Win 3.1 and WFW, if you remember those!). Our internationalization efforts had to apply equally well to our DOS app and our Windows version.

Several of the developers and myself went to a conference, the precursor to VBits, (I don’t remember exactly what it was called back then) and I got a chance to talk with one of the MS internationalization engineers directly.

I’d played with the whole “separate resources for each language” technique and found it workable, but so labor intensive, that I couldn’t imagine anyone but the largest shops actually doing it that way.

The MS guy verified that suspicion. He said (and I’m paraphrasing), “The core team finishes up the project, and ships it, and then the whole project base is ‘thrown over the wall’ and each internationalization team then takes over and internationalized the project into their respective languages, re-tests, etc.”

Ouch.

Now, I’m sure times have changed at MS, but if the comment from Elmue in the article on CodeProject is any indication, they haven’t changed that much.

The internationalization functions I helped build way back then was based on 3 simple concepts:

  1. The original english strings had to remain in the code
  2. Those strings has to actually be used by the code
  3. Those strings had to be easily searchable (say, by a GREP or similar utility) for extraction and translation

Why those first two points?

Because if the english strings remain in the code, the code remained relatively easy to debug and maintain for the programmers.

Further, if the strings are actually used by the code, that meant that during dev and alpha/beta testing, we wouldn’t have any disconnect issues with resources not matching what was needed in the code itself. This is akin to the age old concept of eating your own dog food. The idea of socking strings away in resources and just having a comment in the code as to what the string contained just scared the hell out of me.

Also, it also meant that if the translatable resources are lost for whatever reason, the program would still be able to run based on the “compiled in” English strings. Not ideal, but better than simply throwing errors or displaying blanks.

We accomplished all these goals by embedding all translatable strings (including those in dialogs, etc), into a function call. Something like:

MyString$ = TX$(“This is the english version”, stringcode, groupcode)

Where stringcode and groupcode were optional arguments that indicated, basically, the resource ID of the string and an arbitrary group ID of the string.

Originally, when you were writing or working on code, you’d never even bother entering the stringcode or groupcode args, so your call would look like:

MyString$ = TX$(“This is the english version”)

But, because it was trivially easy to scan for TX$(), when our scanner was run on the code, it could

  1. Extract the strings
  2. Give then ID’s
  3. Rewrite the source code with the appropriate string and group codes as necessary.
  4. Generate a “translator’s file” that contained the string, ID’s and potentially developer comments that would indicate the context of the string and intention (for use by translators to assist with the translation).

Nowadays, with OO, extension methods, reflection, and all the other .NET goodies, seems like this whole process could be vastly more efficient than even what we did back then.

But in the end, we translated the product into 8 or more languages in just a few months with this technique, using no additional developers, and a few native speaker volunteer translators. And it didn’t require any code rewrites and was just as efficient to debug as if you’d left the strings in the code and did nothing about translation at all.

Now, granted, there’s a lot more to internationalizing an app that translating text. You have to worry about icons, input method (when applicable), date, time, and number formats, and even subtle things like color choices, but it was a huge timesaver for an otherwise arduous task.

Closing comment: Why TX$() you might ask<g>? Basically, it was because we didn’t want a huge function name taking up tons of space in the code when it would be used as often as it was. That’s all. As I recall, it is about the only two letter function I’ve ever authored in code. I was never a big fan of the BASICA 2 letter name restriction!

Any translation war stories out there? How have you translated applications?