• Administrator permissions are no longer required to run the application from the Program Files folder; application settings and logs are now stored in the Windows program data folders.
• The application has been tested with and should now work fine with UAC under Windows Vista and Windows 7.
• Summary logs have been added to the end of the logging to report count totals for the various operations.
• Fixed a bug in the new syncing empty folders functionality that caused a neverending loop when the root of either folder was empty.
• Added a “File Filter” property to mapped folders to allow the use of wildcards (*.txt) to restrict which files to sync (as requested by Jason Saul).

Simply run the setup to upgrade to the latest version.

Download UpSync 0.7 Setup
Download UpSync 0.7 Source Code (Visual Studio 2008 required)

Remember to share your thoughts and suggestions!

• Significantly improved error handling
• Delete prompts are now all displayed at once (instead of throughout the process)
• A new “stop prompting and do this for x remaining files” feature has been added
• Code is now StyleCop-compliant (as well as code analysis-compliant)
• Empty folders are now synced properly based on their creation date

You may simply run the new setup and it will automatically upgrade over whatever old version you have installed.

Download UpSync 0.6 Setup
Download UpSync 0.6 Source Code (Visual Studio 2008 required)

Please remember to comment and share your thoughts on the application! :)

To get started, create a class in your project called MessageBoxHelper (or name it whatever you wish). Replace the code in the file with the following code:

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

internal static class MessageBoxHelper
{
    internal static void PrepToCenterMessageBoxOnForm(Form form)
    {
        MessageBoxCenterHelper helper = new MessageBoxCenterHelper();
        helper.Prep(form);
    }

    private class MessageBoxCenterHelper
    {
        private int messageHook;
        private IntPtr parentFormHandle;

        public void Prep(Form form)
        {
            NativeMethods.CenterMessageCallBackDelegate callBackDelegate = new NativeMethods.CenterMessageCallBackDelegate(CenterMessageCallBack);
            GCHandle.Alloc(callBackDelegate);

            parentFormHandle = form.Handle;
            messageHook = NativeMethods.SetWindowsHookEx(5, callBackDelegate, new IntPtr(NativeMethods.GetWindowLong(parentFormHandle, -6)), NativeMethods.GetCurrentThreadId()).ToInt32();
        }

        private int CenterMessageCallBack(int message, int wParam, int lParam)
        {
            NativeMethods.RECT formRect;
            NativeMethods.RECT messageBoxRect;
            int xPos;
            int yPos;

            if (message == 5)
            {
                NativeMethods.GetWindowRect(parentFormHandle, out formRect);
                NativeMethods.GetWindowRect(new IntPtr(wParam), out messageBoxRect);

                xPos = (int)((formRect.Left + (formRect.Right - formRect.Left) / 2) - ((messageBoxRect.Right - messageBoxRect.Left) / 2));
                yPos = (int)((formRect.Top + (formRect.Bottom - formRect.Top) / 2) - ((messageBoxRect.Bottom - messageBoxRect.Top) / 2));

                NativeMethods.SetWindowPos(wParam, 0, xPos, yPos, 0, 0, 0x1 | 0x4 | 0x10);
                NativeMethods.UnhookWindowsHookEx(messageHook);
            }

            return 0;
        }
    }

    private static class NativeMethods
    {
        internal struct RECT
        {
            public int Left;
            public int Top;
            public int Right;
            public int Bottom;
        }

        internal delegate int CenterMessageCallBackDelegate(int message, int wParam, int lParam);

        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        internal static extern bool UnhookWindowsHookEx(int hhk);

        [DllImport("user32.dll", SetLastError = true)]
        internal static extern int GetWindowLong(IntPtr hWnd, int nIndex);

        [DllImport("kernel32.dll")]
        internal static extern int GetCurrentThreadId();

        [DllImport("user32.dll", SetLastError = true)]
        internal static extern IntPtr SetWindowsHookEx(int hook, CenterMessageCallBackDelegate callback, IntPtr hMod, int dwThreadId);

        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        internal static extern bool SetWindowPos(int hWnd, int hWndInsertAfter, int X, int Y, int cx, int cy, int uFlags);

        [DllImport("user32.dll")]
        [return: MarshalAs(UnmanagedType.Bool)]
        internal static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);
    }
}

I won’t go into too much detail describing the above code, because most of it is just Win32 API greek. The gist of it though is there’s a parent static class called MessageBoxHelper that contains two subclasses. The NativeMethods subclass is another static class that simply provides the interfaces into the Win32 API calls. The MessageBoxCenterHelper subclass is instantiated by the parent class, and performs the actual calls to center the message box. I’m not overly familiar with the way callbacks, delegates, and events work when using the Win32 API, so I won’t attempt to explain the logic behind these methods.

Usage

The above implementation may be fairly involved, but using it is extremely easy. Simply call the MessageBoxHelper.PrepToCenterMessageBoxOnForm static method before calling your message box:

using System;
using System.Windows.Forms;

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void Form1_Click(object sender, EventArgs e)
    {
        MessageBoxHelper.PrepToCenterMessageBoxOnForm(this);
        MessageBox.Show("Hello!", "Hello!", MessageBoxButtons.OK, MessageBoxIcon.None, MessageBoxDefaultButton.Button1, 0);
    }
}

It’s worth noting that this code does pass all Code Analysis rules, so you can be confident you won’t have to rewrite any of it to make it pass. I do have one small warning, however; make sure that you always call the PrepToCenterMessageBoxOnForm method immediately before your MessageBox.Show call. Calls to the PrepToCenterMessageBoxOnForm method that are not met with a MessageBox.Show call can interfere with whatever the next form that pops up happens to be, and can result in odd behavior. Still, you’re not likely to want to put the code anywhere else, anyway, and I’ve used it in many enterprise projects without running into any issues.

Let me know if you appreciate this or have any questions or suggestions in the comments!

Update: Many thanks to Matt Stan for pointing out in the comments that the class also works well for centering a folder browser dialog window (by simply calling the PrepToCenterMessageBoxOnForm method before calling the ShowDialog method). It may work for some other dialogs as well, and not just these two. Apparently, however, it does not work for a file open dialog. I’ll be doing a bit of research to see if I can modify the code to support all .NET standard dialogs. I may or may not be successful.

For now, you can assume that it is safe to use on other dialogs, if it works properly. It is probably guaranteed beyond a reasonable doubt to work regularly within the same .NET framework version for these other dialogs as well. Regardless, most likely it will work indefinitely for all future .NET framework versions (unless something is significantly restructured in .NET). The code simply attempts to get a handle to the upcoming window and center it via an event, so it should work generically for most types of windows, and should be plenty safe.

Thanks, Matt!

Update #2: I’ve done some research on the .NET dialogs, relating to the centering mechanism. As well as message boxes, the ColorDialog, FontDialog, and FolderBrowserDialog dialogs do center properly as well. However, the OpenFileDialog and the SaveFileDialog dialogs unfortunately do not. This is because somewhere in the order of events after the new position is given these dialogs automatically center themselves on the screen. This functionality is somehow different from the other dialogs. You can observe this happening if you add “0×40″ (SWP_SHOWWINDOW) to the SetWindowPos method’s flags. If you do this, you can see the dialog come up in the correct spot, centered on the form, and then quickly jump to the center of the screen. Unfortunately, I can’t seem to get around this. The only solutions I’ve seen involve extending the OpenFileDialog and SaveFileDialog controls, which is a completely different direction than this article is taking.

The single biggest clue that a developer either has no idea what they are doing or simply doesn’t care about their code is inconsistency.  We all have different preferences and coding styles, but when a developer can’t pick a particular approach to take they come off as incredibly amateur, and for good reason.  Inconsistent code is difficult to read, and is thus difficult to modify in the future.

The majority (or even the entirety) of the list below revolves around writing consistently styled and consistently performing C# code.  Much of this list is admittedly anal retentive, but all of it is guaranteed to improve the quality and readability of your code.

1.  Use the Code Analysis features in Visual Studio.

The Code Analysis features are anal retentive by nature, as you quickly discover when you begin to use them for the first time.  They are, however, worth their weight in gold; they are the most immediately effective way to improve your C# code.

Each time you build your code, Code Analysis will examine it to be sure that a large and growing list of “best practices” are met, and will create warnings in your Error List if they are not.  You cannot call your code “good” code unless it passes Visual Studio’s code analysis with flying colors.  There are exceptions to this rule, but they are few and far between.

Enabling Code Analysis in your C# Visual Studio 2005 or 2008 project depends on whether you’re working with a Windows or Web application.

For a Windows application, go to your Solution Explorer and double-click the project’s Properties node.  From here, select the Code Analysis tab on the left hand side.  Check the Enable Code Analysis on Build check box, and you’re on your way.  You’ll notice that you can enable and disable any of the various checks individually, but I recommend leaving them all checked unless you’ve found a warning that you’re sure you can ignore.  As I’ve stated previously, the Code Analysis is almost always right.

For a Web application, go to your Solution Explorer and select the root node for your website.  Then go up to the Analyze menu and select Code Analysis Configuration.  From here, check the Enable Code Analysis on Build check box and you’re on your way.

2.  Use regions consistently and effectively.

Nobody likes digging through a huge code file to find a particular method, and C#’s regions help to solve this problem.  Here is an example:

#region Private Variables

private int x;
private int y;

#endregion

#region Public Properties

public int X
{
    get
    {
        return x;
    }
}

public int Y
{
    get
    {
        return y;
    }
}

#endregion

In Visual Studio, regions can be collapsed or expanded using the +/- buttons to the left of the region names in the code window. This helps to make it much easier to find a particular method you are looking for. There are many ways to organize your code with region statements, but I prefer to separate the code by type of construct (variables, constructors, event handlers, methods, properties, etc.) and access modifier (public, internal, protected, or private).

3.  Handle white space consistently.

C# ignores white space, which means you can put extra spaces and lines pretty much wherever you like.  Or, if you’re insane, you can jam ten-thousand lines of code into a very angry single line of actual text, separated only by semicolons.

Here are a few things to consider, though:

• Code with more white space is generally much easier to read.  Less condensed code is easier on the eyes and with screen real estate being as ample as it is these days, there’s little reason to try and jam your code into as few lines as possible.  For the most part, bigger is better.
• Even though code blocks, such as if and while statements, do allow you to omit the curly braces, this generally makes your code harder to read.  The general consensus is to always use curly braces even when there is only one line of code you are executing between them.
• Consistency, consistency, consistency.  If you put new lines after you close blocks of code, be sure you do it everywhere.  Don’t “feel it out.”  Come up with your own strategy (preferably similar or the same to most other peoples’ strategies) and stick to it.

4.  Always specify your access modifiers and choose them carefully.

C# access modifiers are simply the public, internal, protected, and private keywords that you typically place in front of variables, properties, and methods.  Though these are often overlooked, they provide meaning to the functionality behind your code and help to better define the structure of your code through encapsulation.

Here are some grossly oversimplified definitions and uses for the four modifiers.  These definitions are lacking some detail, but should be plenty of information to handle the vast majority of circumstances:

Private members are only accessible to the class in which they live.  All variables, properties, methods, etc. that do not need to be accessed outside the immediate class should be marked as private.

Protected members are accessible to the class in which they live, as well as any classes that derive from (extend) the class.  The protected modifier should be used on variables, properties, methods, etc. that may need to be accessed by classes that may derive from (extend) the current class.

Internal members are accessible everywhere within the current project, but are inaccessible by other projects that might reference the current project.  In other words, using the internal modifier specifies that only classes within the current EXE or DLL file can access the member.  The internal modifier should be used on all variables, properties, methods, etc. that need to be available to other classes within the project, but should not be available outside the project.

Public members are accessible everywhere, period.  There are no restrictions to their access.  This particular modifier is often overused, as the internal modifier is overlooked.  The public modifier should only be used for members or classes that are or would possibly be needed outside of the current project.

As far as defining classes, typically only internal or public are used, depending on if they need to be accessible outside the project.  This, however, does not account for nested classes, which can have any of the four access modifiers.  Always specify your access modifiers to avoid confusion as to when and where the class or member can be used.

5.  Learn the ways to properly use exceptions and stick to them.

C# exceptions are extremely powerful and convenient, but when used incorrectly, they can both slow your application down and hinder output to the end user.

There are two basic rules of thumb to using exceptions properly:

• Never catch an exception when you can check for and prevent the error instead.  A typical scenario is trying to open a file that you’re not entirely sure really exists.  You can wrap the file open code in a try catch, or you can use File.Exists to determine if the file exists before attempting to open it.  Exceptions in C# are expensive, so you only want an exception to be raised if a true error occurs.  If you can predict that it might happen for a particular reason, you should be able to check to make sure that it won’t happen before proceeding.  This will help to improve performance significantly.
• Also, never catch the root Exception class, or any high-level, broad exception.  If you catch an Exception class, and you incorrectly assume that the user didn’t fill in a particular field as a result, the user will see your incorrect error message and be unable to see the actual error that occurred.  This is unacceptable.  Instead, research the methods you are calling to determine the particular types of exceptions they raise, and catch these specific exceptions.  This way, if something occurs that you didn’t expect, the end user will see the detailed error message anyway.  The MSDN documentation does a great job of providing you with all of the details you need regarding every exception that is possible for every single method in the .NET framework.

6.  ALWAYS use using statements.

In case you’re not familiar with the syntax of using statements, here is an example:

using (StreamWriter writer = new StreamWriter("C:\\file.txt"))
{
    writer.WriteLine("Hello!");
}

Using statements can be used wherever you’re instantiating an object that is IDisposable (can be disposed using the Dispose method).  If you don’t actively dispose objects that support the IDisposable interface, you’re asking for all sorts of performance and memory leak trouble.  Here are the advantages of using statements over calling the Dispose method directly:

• Even if an exception is raised within your using statement block, the runtime will still ensure that the object gets properly disposed.  This is automatic with the using statement and is impossible without it.  Before using statements were added in .NET 2.0, you had to attempt to dispose of your objects within a catch block, which was far from error-prone.  Never take this approach.
• Using statements help to visually define the scope of a variable that requires disposing.  You can quickly and easily see the start and end of the lifetime of the variable.  Once you are in the habit of consistently using using statements to dispose of objects you will very rarely (if ever) forget to dispose of an object, because of the block nature of the statement.
• Using statements even allow you to return from a method within the statement.  The object is still disposed of properly in this situation.  In other words, if you use a using statement, the object is GUARANTEED to be disposed of despite any and all circumstances.  That’s a pretty big and valuable promise.

There is much more to writing good C# code than these 6 rules, but these are the rules that I see consistently broken that are driving me to an early grave.  Let me know in the comments if you think I’m missing something important or disagree with any of my statements.

If you use it, let me know!  I’m interested in any kind of feedback.

Download UpSync 0.5 Setup
Download UpSync 0.5 Source Code (Visual Studio 2008 required)

I’m open sourcing the project, and I’ll have the setup and the source code for version 0.5 up very shortly.  It works properly on Windows XP, Vista, and even Microsoft’s new, unreleased Windows 7 (the screenshots are from Windows 7).  It’s written in C#, my favorite of the .NET languages, using Visual Studio 2008.

Here are some of the key features that have already been implemented:

• Any number of folders can be synced with separate settings for each folder.
• Sync in one direction, the other direction, or both directions with no interaction necessary.
• Specific settings for handling deleted files allow for all possible situations.
• Syncing engine uses file dates and times to ensure the most recent version of files are replicated.
• New files in either folder are automatically handled correctly and copied over to the other folder.
• Sync process can be entirely automated or manually run.
• Syncing engine logs every operation in complete detail so there is never any confusion as to what files were changed.