dennis' blog

Details are in the build notes.

My personal favorites are numerous Studio improvements, including opening each file on only one tab, instead of 2 separate tabs for designer and source code, and an updated Workspace Explorer which now shows all files included in the current project.

See the forum post/release notice for details.

Code encapsulation simplifies maintenance. The more abstracted and isolated a routine is from a larger code base, the easier it will be to adjust, test, and if needed, replace later.

This came to mind recently when I wrote a short routine that determines if a mapped drive is a local drive:

[DllImport("mpr.dll")]
static extern uint WNetGetConnection(string lpLocalName, StringBuilder lpRemoteName, ref int lpnLength);

// returns whether the current drive is local
internal static bool IsLocalDrive(String driveName)
{
    bool isLocal = true;  // assume local until disproved

    // strip trailing backslashes from driveName
    driveName = driveName.Substring(0, 2);

    int length = 256; // to be on safe side
    StringBuilder networkShare = new StringBuilder(length);
    uint status = WNetGetConnection(driveName, networkShare, ref length);

    // does a network share exist for this drive?
    if (networkShare.Length != 0)
    {
        // now networkShare contains a UNC path in format \\MachineName\ShareName
        // retrieve the MachineName portion
        String shareName = networkShare.ToString();
        string[] splitShares = shareName.Split('\\');
        // the 3rd array element now contains the machine name
        if (Environment.MachineName == splitShares[2])
            isLocal = true;
        else
            isLocal = false;
    }

    return isLocal;
}

There is a post on stackoverflow asking how to do this, and, like many others, it has several answers showing several ways to do this. So, is my method correct? This code seems to work, but I’ve been programming long enough to know that code that “seems to work” doesn’t necessarily work in every circumstance and could have other negatives, such as performance issues.

So, knowing that this code I may have to tweak or replace at some future point in time, I will try to encapsulate it as much as possible to make it easier to work with in an isolated manner later. By keeping the code in a separate method, I can easily use a unit test to try it in various test scenarios without affecting any other code.

Of course, this is a very simple scenario, which made it perfect for this post. It can be much tougher to abstract and isolate more complex code, but that doesn’t mean we shouldn’t strive to do so whenever possible.

Once in a while, I try to send an email in Outlook and I get an error

An internal support function returned an error.

How is this error helpful in any way?

What function and what error and what can I do about it? If you’re not going to tell me that, then why bother telling me anything?

It tells me, the user, that the email wasn’t sent, but beyond trying it again, there’s absolutely nothing useful this error tells me. It’s not telling me a reason for the error and it’s not giving me any information for improving what I did to improve the outcome the next time I try to do the same thing.

So, what do I take away from this experience as a programmer?

• If I create an end-user type of message, I’ll try to limit the amount of technical information in the message and try to tell the user what to do to resolve the error if that is not apparent from the message itself.

  For example, for a typical end-user, a more appropriate message might have been:

  An error occurred when trying to send this message. Try sending it again.
  

• If I create a more technical message, one that contains more useful information for the programmer (me), I’ll try to expose enough technical detail information so that when the message gets back to me, I’ll know where to look in my code to find the problem.

  For example, a better technical message might have been:

  Internal function XYZ returned error 1234. Please report this error detail to your developer. Try sending the message again.

  
  

Highlights include:

• AJAX Library Support for Web Applications – Beginning with revision 2009, the AJAX library will be officially included and supported in Visual DataFlex. Plus The Visual DataFlex 2009/15.0 Web Application Server now provides JSON support.
• Visual DataFlex Studio Enhancements – Include Design time anchor support, improved breakpoint panel, easier text selection in Code Explorer, a new Go-back option to provide “go back” points in a file, faster loading and running of large applications in the Studio via a Dependency Cache rewrite, and Debugger improvements including Conditional Breakpoints.
• Runtime Improvements – Include new Array functions, new Pos and RightPos functions, and improved icon resource handling.
• New and Improved Classes – A number of new classes and improvements to existing classes have been implemented. New classes include Hyperlink, Scrolling container, and Splitter container. Tooltips are also now supported in classes.
• Library Enhancements – Improvements have been implemented that encourage the development and use of Visual DataFlex libraries within and across development teams.

My personal favorites are conditional breakpoints (yes!) and a simply hyperlink class (cLinkLabel).

See the forum post/release notice for details.

Last Saturday I attended Austin Code Camp 2009. This was the second year I attended and I’m already looking forward to next year! Austin Code Camp is an annual event of a full Saturday of .Net-related classes and presentations, all completely free to attendees like myself.

My biggest problem was picking which sessions to attend, or worse, which ones not to attend.

I eventually chose to attend Sneak peek at C# 4.0 by Jimmy Bogard, who gave a similar session about C# 3.0 at last year’s camp, and 2 excellent 2 hour SQL Server sessions by Anil Desai, SQL Server Reporting Services: Report Creation and Deployment and SQL Server Performance Monitoring & Optimization. All 3 sessions were awesome, thanks guys!

Thanks to John Teague, all presenters, the Austin .Net Users Group, the sponsors and everyone else who helped make this event happen!