I bent my Whidbey!

Ok, this is weird. For friends / family who come here not knowing what "Whidbey" is, please, just move along.

So, I've been using Whidbey for a while now and I've never experienced anything as weird as I experienced today. I'm posting this to re-hash my experience, and hopefully find someone else who's experienced this problem, and maybe, just maybe have someone tell me why it happened.

First, some background on the project I'm working on. This project requires the implementation of two seperate but very similar and intertwined, applications. Because of the shared elements, I felt it best to create a Solution consisting of three projects -- two main Windows Forms projects and a common Class Library project. The mains reference the common project and use the helper methods, 'middle-tier' business objects, common tool form windows, project-property dialogs, etc, that the common project serves-up.

At some point I guess I did something wrong this morning because I opened a code view, and I could type characters and numbers, but I couldn't press enter, backspace, delete, or the arrow keys. It's almost as if any key that wasn't an [a-zA-Z0-9] key was just discarded by the IDE. I could highlight code and copy/cut/paste from the right-click context menu, but I couldn't use the ctrl-[cxp] shortcut keys to do the same thing. I also noticed that when I was typing, Intellisense wasn't poping up.

Ok. . . Weird.

I tried many things.

• Closed all open files -- nope.


• Checked everything into Source Safe, then back out -- nope.


• Closed the solution, and closed VS2005, and opened it back up -- nope.


• Rebooted my PC -- nope.


• Deleted the bin and obj directories from my 3 project directories and re-opened the solution -- nope.


• Reset all VS keyboard shortcut customizations -- nope.


• Rebuilt a 'clean' copy of the solution from Source Safe -- nope.


• Opened VS2005, created a dummy project -- NO PROBLEMS!.
  ("Ok, so it seems like it's something with my solution." I thought.)


• Opened a different, pre-existing, previously known-to-be-working project -- NO PROBLEMS!.
  ("Yup...it's definately something with my solution.")

I'd almost run out of options (I really didn't want to try the uninstall/reinstall 'option',) when it became crystal-clear that it was something in my solution that was causing the problem...but what? There were no build errors, the application ran, and I can seemingly view all designers and code windows, I just couldn't edit code!

So, how did I 'fix' it? I'm not sure if I fixed it, or if it fixed itself, but here's what I did:

• Fired up my 'broken' solution


• Confirmed that, yes, it was still broken.


• File->New->Project. Created another junk project/solution. (ie: I never closed Visual Studio.)


• Confirmed that, yes, in this junk project/solution, there were no problems with the code editor -- Intellisense was working, and so was enter/delete/backspace.


• File->Recent Projects->MyBroken.sln to re-open my 'broken' Solution.


• The Code Editor Worked.

- W - T - F -???

What was I doing before it 'broke'? Well, to tell you that, you need a little more background info.

Remember that the main form in the main projects use tool windows provided by the common project. As such, I wanted a way to handle any exceptions that might happen in the tool windows in my main projects. (ie: The main projects have 'centralized' exception displaying/logging, and I want exceptions that happen in the tool windows (provided by common,) to basically pass the exception to it's parent form for user-notification and logging.) To facilitate this, in the common project, I made a simple derived class that looked something like this:

public abstract class MySpecialForm : System.Windows.Forms.Form {
 protected virtual void ExceptionHandlerCORE(Exception ex, string logfile) {
    ...
 }

 public virtual void ExceptionHandler(Exception ex) {
    ...
 }
}

Then, in the main project, it's main form is derived from MySpecialForm. It overloads the ExceptionHandler method, calling base.ExceptionHandlerCORE(...), passing in a user-specific logfile.

This solves my requirement of having the common tool windows 'report' exceptions back to their owner form. All these tool windows need to do is something like this:

try {
   // something that throws an error
} catch (System.Exception ex) {
 MySpecialForm owner = (MySpecialForm)this.Owner;
 owner.ExceptionHandler(ex);
}

At this point I hear some of you guys hollaring: "You're MySpecialForm, it can't be declared abstract if you ever expect to use it in the Visual Studio Designer!" You're exactly right! It was with the discovery of this little fact that the IDE started acting weird, and the Code Editor decided to start acting up on me.

I tried opening the main project's main form, and instead of getting my form, I get a page telling me that MySpecialForm is declared abstract, and I can't work in the Designer because of that. Oookay. I closed the designer, went and modifed MySpecialForm so it wasn't abstract, rebuilt the Common project, tried re-opening the main project's form in the designer, but nope. The same error. *sigh* Stupid thing isn't seeing my recompiled common. I rebuilt the entire solution, which in the past has fixed problems where the main projects couldn't 'see' the recompiled changes in their referenced common assembly. I even tried removing and re-adding the reference to the compiled common assembly -- the error persisted. It was some where around that time that the Code Editor started acting wonky -- I think I closed/restarted Visual Studio in an effort to try and get main to refresh it's references, and then the weirdness in the code editor began.

And with that...I'm out. I've got to thank my friend Mr .NET for helping me try to figure this out. I've also got to chastize him for not knowing the answer! heh.

With that, I leave the floor open. Someone tell me they've seen this before!