Thursday, May 31, 2007

Blogger FTP Frustrations

I haven't been able to publish a blog post for a three or so weeks now because of a problem in the Blogger FTP publishing operation. The last post was queued up in the Blogger database wasn’t able to be written to the web site. The Blogger error output had lots of repeated lines similar to the following (after a long timeout period)



/blogger_ftp/archive/2007_05_01_archive.html java.net.ConnectException: Connection timed out
/blogger_ftp/2007/04/silverlight-based-on-microsoft-net.html java.net.SocketException: Broken pipe
/blogger_ftp/2004/06/microsoft-developer-target-profiles.html java.net.SocketException: Broken pipe


There’s a bunch of FTP related problem descriptions on the Blogger group pages, but no real consistent solutions. There were entries like “created another FTP account and then it just started working”. I sent a couple of submissions to the black hole that is Blogger support. In the end I decided to set up a Linux FTP server using dynamic DNS and then reconfigure Blogger to transfer to that temporarily. All the FTP transfers succeeded, so attention moved to the web hoster.


At first the hoster response was something along the lines of “document step by step how to reproduce the problem”. Sometimes it seems that support staff and software or software service companies don’t actually read the first couple of emails you send them. I do get incredibly frustrated when support people ask for a step-by-step instruction set on how they can reproduce the problem even when the contact email explicitly indicates that the problem can’t be reproduced at will by the support person and the reason why.


In an effort to resolve the problem, I quickly looked at alternative blogging platforms. Wordpress was very promising. It was easy to import all the Blogger posts, but the big problems for me were the inability to embed flash content in posts or import third party themes. I had a quick look at Community Server and dasBlog, but didn’t really want to go through the setup and ongoing maintenance hassle. Wordpress hosting solutions were an option, but they cost as much as my existing web site. In the end, the approach taken was to user Blogger custom domains. Yes Blogger is a dog of a blogging platform that is moving glacially considering the resources that Google has available. Regardless its a pain to move the blog elsewhere.

Saturday, May 19, 2007

ObjectDisposedException closing Form in click handler

Okay here's a weird .NET Windows Forms error scenario. One of the applications had a scenario where an ObjectDisposedException was occurring, but for only one of the users. The other users that worked that the particular application functionality involved did not experience the error. I finally managed to reproduce the problem in the office by initiating the application task, clicking the “Create Job” button and then immediately going to another application and flipping between other windows that have nothing to do with the application. My guess is that the user that experiences the issue interacts with the system in a particular GUI manner that uncovers the problem.


The stack trace when the ObjectDisposedException looks like this:



  System.Windows.Forms.dll!System.Windows.Forms.Control.CreateHandle() + 0x1ff bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.Handle.get() + 0x77 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.PointToScreen(System.Drawing.Point p) + 0x38 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs mevent = {X = 36 Y = 7 Button = Left}) + 0x79 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseUp(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) + 0xf2 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x544 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.ButtonBase.WndProc(ref System.Windows.Forms.Message m) + 0x151 bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Button.WndProc(ref System.Windows.Forms.Message m) + 0x2b bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0xd bytes 
  System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0xd6 bytes 


The Button.MouseUp method attempts to identify where on the screen the mouse up event occurred when the button has already been disposed. Being able to reproduce the problem in the office, at least allowed me to identify which button was involved. The button click handler code is pretty standard for a button that does some work then closes the form:



        private void HandleCreateClick( object sender, EventArgs e )


        {


            // Application specific processing goes here in the real code.


 


            Close();


        }


 


After much experimentation using the debugger and Reflector, it looks like under normal circumstances the Close() causes a side effect of the button losing focus, which then clears internal System.Windows.Forms.Control flags which ensure that the OnMouseUp method doesn’t attempt to do any mouse-up event handling. For some reason, in my particular application scenario, the OnLostFocus method is not called and OnMouseUp processing attempts to get the mouse coordinates which then causes the ObjectDisposedException to be thrown. No matter what I tried, I could not reproduce the problem in a simplified project that could be forwarded onto Microsoft to look into. The following workaround was used to stop the problem happening in the application:



        private void HandleCreateClick( object sender, EventArgs e )


        {


            // Application specific processing goes here in the real code.


 


            // The following line is a workaround for a problem where the createButton's


            // MouseUp event was throwing an ObjectDisposedException. In most scenarios


            // where a button click event handler Closes the Form, a LoseFocus event


            // resets the internal flags which causes the MouseUp event processing to


            // skip any attempts to access button information. For some reason this


            // createButton scenario would occassionally not get the LoseFocus event


            // and cause an exception to be thrown. Setting the Enabled flag to false


            // is a workaround which clears internal button flags so that no


            // MouseUp processing occurs. This works around the problem.


            createButton.Enabled = false;


 


            Close();


        }