The problem is the DataGridView is not double-buffered by default, nor is there any visible property on the DataGridView object to set it as double-buffered.

Google to the rescue!

Thanks to the guys at StackOverflow.com for this elegant solution that uses reflection rather than defining a custom class.

typeof(DataGridView).InvokeMember(
   "DoubleBuffered",
   BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.SetProperty,
   null,
   myDataGridViewObject,
   new object[] { true });

[Via: stackoverflow]

This is fine, unless you only want one instance of your app to be running at any one time. Each time an associated file is opened, a new instance of the ClickOnce app will be launched. If your single-instance app is open and you try to open an associated file, the reference to the file will be lost when the new instance detects that the original instance is running and terminates. Grrr.

However, you can get round this. After detecting that there is another instance of your app running, simply pass the file reference to the original instance before closing.

Note the callback is made using an IpcChannel rather than a TcpChannel. If a TcpChannel is specified, Vista and Windows 7 will require permission from the user to allow communication through the firewall.

Here is the code:

            // Single instance checked
            bool IsFirstInstance;
            Mutex theMutex =
                new Mutex(false, "Local\\" + Application.ProductName, out IsFirstInstance);
            string[] theActivationData =
                AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData;

            if (IsFirstInstance)
            {
                IpcChannel theChannel =
                    new IpcChannel(Application.ProductName);

                try
                {
                    ChannelServices.RegisterChannel(theChannel, false);
                    RemotingServices.Marshal(this._MainView, "MainView");

                    this.MainView_Show();

                    this.ConsumeLaunchParameters(theActivationData);

                    Application.Run(this._AppContext);
                }
                catch (SocketException) { }
                finally
                {
                    ChannelServices.UnregisterChannel(theChannel);
                }
            }
            else
            {
                if (null != theActivationData &&
                    theActivationData.Length > 0)
                {
                    try
                    {
                        MainView theOriginalMainView =
                            (MainView)RemotingServices.Connect(
                                typeof(MainView),
                                "ipc://" + Application.ProductName + "/MainView");

                        theOriginalMainView.ConsumeArguments(theActivationData);
                    }
                    catch (SocketException) { }
                }
            }

            theMutex.Close();
            Application.Exit();

Since my app uses a centralised controller system, I had to add the following code to the MainView form to pass the arguments back to the controller:

        public void ConsumeArguments(
            string[] theArguments)
        {
            // Note that it is not allowed for non-UI thread to access
            // controls on the form, instead, we should use the Invoke method of the form
            // to execute a delegate on the UI thread that own's the control's underlying
            // windows handle.
            if (this.InvokeRequired)
            {
                this.Invoke(
                    new MethodCallback(ConsumeArguments),
                    new object[]
                        { theArguments });

                return;
            }
            else
            {
                if (null != this.ArgumentsConsumed)
                {
                    this.ArgumentsConsumed(theArguments);
                }
            }
        }

        public event MethodCallback ArgumentsConsumed;

        public delegate void MethodCallback(string[] args);

The console app has elevated privileges that are passed on to the re-launched ClickOnce app.

If I didn’t include this, the application would fail with (what I assumed was the first of many permissions errors) a registry access error. I decided to remove the UACLauncher and debug each error as it occurred. All my ClickOnce applications that require registry access to store settings store them in the LocalMachine hive. After googling the registry permission error, the main suggestion that came back was to move the settings to the CurrentUser hive.

Fair enough, but upon publishing the new version, there were no more errors. It seems that the only thing the app was doing that required administrator-level access was to attempt to write to the LocalMachine hive of the registry.

It was only in a revelation whilst I was in bed last night that I wondered if I could use Dropbox’s Public directory as the target to publish my files.

It works! Here’s how…

1. Install the Dropbox client,
2. Once installed, navigate to the Public sub-directory in whichever directory you assigned as the Dropbox directory,
3. Right-click on the “How to use the Public folder.rtf” file,
4. In the Dropbox menu item, click “Copy Public Link”,
5. Paste it into any notepad application,
6. In Visual Studio, in the Publish tab of your project’s properties, use the following information (substituting your own locations as required):
   • Publishing Folder Location: C:\My Documents\My Dropbox\Public\Project1\
   • Installation Folder Location: http://dl.dropbox.com/u/xxxxxx/Project1/ (Paste the link from step 4, removing the How to use the Public folder.rtf portion and adding the project directory)
   • Click the “Updates” button,
   • Update Location: http://dl.dropbox.com/u/xxxxxx/Project1/ (I always do this just to be on the safe side)
7. Publish
8. That’s it! The files will sync to the Dropbox servers, and the project is deployed!

Now all you have to give out is the URL to either the http://dl.dropbox.com/u/xxxxxx/Project1/index.html file if you chose to generate one in your publishing options, or http://dl.dropbox.com/u/xxxxxx/Project1/setup.exe directly.

Easy-peasy, lemon-squeezy.

It uses concurrent AJAX, calling a lightweight PHP+XML web service layer to communicate with a Microsoft SQL Server.

The management application that the staff at the Links use to administer the bookings is written in C#, using C# web services back to the SQL Server.

Like the online booking, the AJAX layer is based on "The Ultimate AJAX object" by Patrick Hunlock, which I’ve found to be one of the only objects that elegantly supports concurrency.

It also allows you to rate each track, allowing you to differentiate between different versions of the same track by different manufacturers.

Jim Addison, or Jivin’ Jim as he is known, is a professional DJ and KJ, and he was excited about the application, as it makes it a lot easier to find and play karaoke tracks during a live show, and he’ll be using for all his karaoke shows.

He is also, incidentally, the guy who runs C.A.R.R.O.T. (Care And Rehoming Rabbits Of Tayside) where we got Emily.

It uses concurrent AJAX, calling a lightweight PHP+XML web service layer to communicate with a Microsoft SQL Server.

The management application that the staff at the Links use to administer the bookings is written in C#, using C# web services back to the SQL Server.

The AJAX layer is based on "The Ultimate AJAX object" by Patrick Hunlock, which I’ve found to be one of the only objects that elegantly supports concurrency.

Since this is a personal project, I didn’t want to use our SVN code repository at Computa, so I had a look at Google Code and so far, so good.

Anyway, you can check it out if you want at http://code.google.com/p/rapidspider/.

My application is deployed via ClickOnce. Unfortunately, it appears that Google Code only supports standard downloading. Until it supports being deployed to, you can install it from http://www.ne0ge0.com/clickonce/RapidSpider/.

The VeriSign timestamping service is being upgraded to provide a higher-level of security. The timestamping service currently uses the hash algorithm called MD5 to create the timestamp. Although no actual incidents of breaking MD5 have been reported, modern computing power is making it easier to mount attacks against MD5.

The timestamping service is being upgraded to use the hash algorithm called SHA-1 to create the timestamp. Microsoft has confirmed that an application signature that contains a timestamp created with the

SHA-1 hash algorithm is validated correctly on Windows Vista, Windows 2003, Windows XP, and Windows 2000.

The upgrade will occur by July 15, 2008.

Who may be affected: Anyone using the VeriSign timestamping service.

How will they be affected: There should be no issue for users signing applications on or for Windows Vista, Windows 2003, Windows XP, and Windows 2000. Application signing on or for earlier versions of Windows, or for non-Windows platforms, may result in signatures not being successfully validated.

What should they do: Use a more recent version of Windows, or sign the application without a timestamp.

Please use the following contact information if you have questions or concerns about this upgrade:

https://www.thawte.com/ssl-digital-certificates/technical-support/

[Via: Thawte Technical Support]

• AJAX-style Asynchronous Progress Dialog for WinForms – A base class for adding a rich asynchronous progress animation to any Form

• xml to json – convert xml to json – faster, stronger and more comfortable

• Running a Web Site in Kiosk Mode with C# – Running a Web site in kiosk mode and disabling some normal keyboard control functionality to limit a user’s ability to depart from kiosk mode

• pInvoke.net – Primarily a wiki, allowing developers to find, edit and add PInvoke* signatures, user-defined types, and any other information related to calling Win32 and other unmanaged APIs from managed code