VB.NET

Recently I had occasion to write a moderately complex component that used "automation" (using the old fashioned COM term) to communicate with the Microsoft Office Excel application installed on the same computer. In this post I share several tips and tricks that may help you in your Excel automation adventures.

Some thoughts on Dan's .NET IsDate() and IsNumeric() post.

For some reason they left IsNumeric() and IsDate() functions out of .NET. I end up needing these is almost every non-trivial project. In this post I share C# and VB.NET versions of the functions I use. Your mileage may vary depending on your performance needs; if you're calling these thousands of times in a loop, then be sure to test them against alternate techniques. (Updated in light of new native IsNumeric() and IsDate() functions in VB.NET 2.0.)

D'oh, as my Eldest Yi Number One Son would say. I got a development laptop but delayed getting Visual Studio with MSDN because I need to better manage my finances, and I need neither toy for my six day week job as a LaoShih (teacher) in dear old Hong Kong. So I downloaded and installed Visual Basic Express. But then I asked myself, well why not get as another interim product, C Sharp Express?

I was surprised at how technically "unsafe" certain very common aspects of managed code use were under .NET Framework 1.0 and 1.1. Particularly, any kind of Interop activity in a multi-threaded environment has some potential resource leaks and even security holes.

This an open discussion thread for the developer.* article ".NET Exception Handling," by Edward G. Nilges. If you haven't already, you can read it here, then add your comments below.

Imagine my surprise when I was able to download what looks like a full scale .Net development tool, aimed at but not restricted to newbies, this Visual Basic Express thing.

Dispose() is merely a convenient place for a class developer to place any resource clean-up code, in the hope that clients will call it. Dispose does not free the managed memory allocated for an object.

threadableStateful illustrates an approach to .Net multithreading whose simplicity demonstrates why I avoided COM threading but use it in .Net.

I think the approach is scaleable. It is based, first, on preserving all nonthreading standards for .Net stateful objects including the idea of Usability: an object is Usable after a successful constructor and prior to dispose() (which must be exposed) or a serious internal error (an error other than the attempt to set the object's data to invalid values).

threadableStateful, below, is a Form which contains a Private class, threadableStateful. threadableStateful accepts a list box passed by value and an inidcation of whether locking is to be "precise". It then clones a random number of copies of itself and starts each one in a new thread.

One problem with a tendency to get outa hand in mixed VB.Net and C# environments is the issue of Optional parameters. In VB, Optional parameters may appear or not as in

Public Function trivialPursuit(ByVal intNeeded As Integer, Optional ByVal strOptional As String = "")

intNeeded must be specified, but strOptional may be omitted as in

trivialPursuit(intNeeded)

...because throughout history, second-rate intellects have proclaimed the superiority of one natural language over the other.

French is considered by the xenophobic, conservative Frenchman was considered to be more "clear and logical" than English or German. This is a language in which "personne" abbreviates "no personne" and in ordinary speech, when I say "personne n'aime Bush" I don't mean "there exists at least one person who likes Bush": I mean nobody likes Bush.

Of course, this telegraphic shorthand, while it would be ambiguous in a programming language, is perfectly acceptable in speech because (1) many personnes understand it in context and (2) the usual Gallic tonality and shrug, coupled with the Gauloise being lit communicates the meaning.

I was working, today, on a tool to visit all controls in a VB.Net form while emitting events for control visits. It worked fine as long as I set its property to not spawn independent threads, but it worked not so great when I did set this property.

I realized that because the controls and subcontrols were being visited "postorder", with all children of any form, group box, or other control with a nonempty collection of Controls being visited (by starting a thread using a new traversal instance) BEFORE visiting the parent, at all levels, I'd made an error.