Autocomplete Extender Lesson Learned, Part Two

It turns out that the problems with the AutocompleteExtender actually go even deeper than the dispose problem. Or not as deep, depending on how you think about it. At some point in my effort to make my website pretty, the problem of the extender not extending after a partial postback reappeared. After spending a large, large amount of time on this, I found reference to another bug in the AJAXControlToolKit that happens if you programmatically set the focus back to the textbox associated with the extender control after doing a postback (partial or not).

I removed the set focus statement, and I am back in business. Again.

But dude, seriously?

Converting from a Web Project to Web Site

If you've converted from a VS2008 Web Project to a VS2008 Web Site, and tried to bring pages from one over to the other, you may have been stuck with the issue that your code doesn't see the objects created by the aspx. i.e. the text boxes, the drop downs, etc.

After you spend a while trying to match up namespaces, and letting Resharper fix a bunch of issues for you, you may still be stuck.

Here's one thing to check:

In your page directive, check to see that the compile has chnaged the CodeBehind attribute to read CodeFile. That's got me twice now. That's reason enough to blog about it.

AJAXToolKit Autocomplete Extender Lesson learned

I was migrating a series of web pages from a small web project in VS2008 to a large client web site (not a web project, a web site). One of these pages included a predicitve text field which I used the ASP.NET AJAXToolKit to implement. The Tool kit worked almost flawlessly. I say almost flawlessly because there is a major bug which prevents the AutoCompleteExtender from working if you host the control in an update panel and you have already done a partial page postback.

Luckily Aaron Schnieder has already solved this issue.
http://weblogs.asp.net/aaronschnieder/archive/2008/03/11/ajaxcontroltoolkit-autocompleteextender-bug-in-an-updatepanel.aspx

Not sure why they haven't kicked out a new version of the tool kit onto Codeplex yet, but they haven't, so you must apply this change yourself.

So after I finished migrating my pages and my web service into the web site, I went to try to run my page with my autocomplete extender, and viola - WTF? Nothing happened. Crap.

Dork around with the pages. Add break points. Google a lot. Did I recently install any VS2008 service packs? Possibly. Uninstall them. Still nothing. Google some more. Add a new web site to my solution, with code right from the AJAXToolKit (converted to VB.NET of course). Still nothing. Two more hours of trial and error. Call it a night.

Log on this morning. Dig in again. More Googling. Hey, what's that? In the new Web Service code behind file I added?

' <System.Web.Script.Services.ScriptService()> _
How come that line is commented out? By default? Yikes.

Remove the comment. Try the app again.

Presto. Back in business.

UM, um, I mean UML

I'm taking a little break from Windows Workflow to refresh my knowledge of UML and Use Cases. To tell the truth, I never really bought into the whole use case stuff at my previous job. I can give a hundred excuses, all valid of course, for why I didn't believe in UML, but it was mainly because I didn't see my customers buying into the process of software development. They wanted the software. They wanted it now. They didn't want to do any work. Whatever tools we used, whatever diagrams and documentation we drew up, was for our own purposes. They never saw the use in it. By the time the diagrams were done, there was a new crisis du jour, and the last project was already passe.

But I was in a meeting with a new client last week, and one of the reasons I was being brought in to help with this project was to help build an industry standard set of requirement documents which could be handed off to the developers, whether it be my team, or someone else. I was there to do the architecture.

And on the way home that night, it hit me. I might not be there in six months to answer a developer's questions on what was needed. And they might take my name in vain. And they might say that I was incompetent. I can't afford that.

So I picked up my UML book this morning and started re-reading. Realistically, most of the stuff I already knew, but I had never formalized the terminology. I have never put UML / Use Cases on my personal resume because I lacked this formal experience with the process. So with the goal of not looking incompetent, and knowing that I would immediately apply this knowledge to my current daily responsibilities, I am digging in and now seeing the positive side of learning something that I consider 'non-technical'.

In fact, after reading the first 5 chapters this morning, I'm convinced that I can give this book to a project manager I work with, and that with both of us using this style my consitently, we will be better able to understand each other.

Who da thunk it?

Initial Impressions of Windows Workflow Foundation

In my last post, I mentioned I was reading Pro WF Windows Workflow in .NET 3.5 by Bruce Bukovics. I also used the words Whoop-Tee-Doo.

Well, I'm now 335 pages into the book, and into the concept of state machines, and this morning I finally had an 'Aha!' moment. See I've been trying to solve a problem at work, and knew that Workflows would probably help me, but the Sequential Workflows weren't blowing my mind. They just seemed like a lot of overhead to implement something that I could do inmany other ways.

However, the State Machine Workflows are definitely something I can see real possibilities for. I'm going to mock up my problem as a state workflow today, and see if I can get it to work.

I have two concerns:
1. Will I be able to call a .NET 3.5 Workflow DLL from a .NET 2.0 Application. I think so, as long as the .NET 3.5 Framework is installed on the clients (which it is)
2. Should I, as the architect, introduce another new technology into an application which is already difficult to support, even if it makes the problem I am trying to solve easier to solve. I am conciously trying to not alter the core of the application because of the size of it and the cost of fixing stuff that isn't broken, but the framework of the application is really limiting what we can do, and I think I can just peel out some pieces and make the application better. I also don't want to be the only one able to support it going forward, and if the rest of the team doesn't take their education in the new technologies as seriously as I do, I could be painting myself into a corner.