Month: <span>February 2009</span>

I’ve never been a fan of Internet Explorer. I used Netscape starting with version 2.0 and only switched when Firefox came around. So I’ve never bothered to upgrade my XP development machine to IE 7. Then I read this post from Scott Hanselman about how a sizable chunk of his visitors are still running IE 6. He linked to a web site that’s actually devoted to getting people to upgrade. I’ve heard all the stories about IE 6’s particular horribleness, such as poor CSS support and a generous helping of security holes. But I didn’t care.

Except Scott somehow made me care. So I upgraded my machine and I must say, IE 7 loads pretty fast, way faster than Firefox 3. I suppose it’s good to stay current, but when Microsoft feels it has to change practically everything with each new release of software, it makes it hard to really want to upgrade. I dread the day I’ll have to move to an OS beyond XP. Maybe Windows 7 won’t be as bad as Vista, but I’m not going to hold my breath.

You would think spell checking a text box on a web form would be a snap. Firefox manages to do it the background: simple, easy, and it always works. But Telerik decided to go a different way, the ridiculously hard way.

I’ve noticed that the more complex controls in Telerik’s ASP.NET suite actually render as three or four separate HTML elements. Typically one is visible and the others are hidden. It makes sense to do it this way if you need to store several disparate pieces of information, or you need to do a lot of juggling on the client to implement some magic piece of functionality. But it means updating the actual content is trickier. The RadSpell control works this way.

What I wanted to do was automatically update some text after the user initiated and completed a spell check. A Telerik knowledge base article suggested manually updating the text box from their RadSpell control’s client-side OnClientDialogClosing event handler. The problem there was that event doesn’t seem to exist. There’s an OnClientDialogClosed event, which I thought might be good enough, but no dice. I couldn’t get the text to update.

I dug a little deeper and found an alternate approach, one that would give the RadSpell control the ClientID of the text box to update so it could do it for you. That didn’t work out so well either. It would update the text but as soon as I clicked in the text box it would revert to the misspelled text.

After fiddling with it for the better part of an afternoon, I got it to work in both IE and Firefox using OnClientDialogClosed. I don’t know what I was missing before, but it now correctly updates the user’s text. Afterwards I had to wonder if there wasn’t a better way. Are today’s super-duper whiz-bang third-party controls just so complex that the simple things become the hardest?

Telerik recently managed to brighten my day. I’ve been using their WinForm and ASP.NET suites for a few weeks now, long enough to realize there are several things about them that vex me. Case in point: the text boxes.

I have an application with a web front end and a small WinForm back end that will be used by administrators. I wrote the admin module first, and it needed to allow the user to input and edit currency values. The WinForm suite only has one masked text box control, so that’s what I went with. But it isn’t quite as nice as I hoped, probably because it has to be all things to all people. It treats its values more like text than numbers. If you assign a numerical value to it that is not as wide as the overall mask, it won’t right-justify the text, which for dollar amounts is very wrong. So I had to prefix shorter values with zeroes. I could set the text so the placeholder character is shown rather than the zeroes, but that falls apart as soon as the user touches the control, even just by tabbing over it. The zeroes pop right up. It’s very minor, obviously, but you’d think that after paying a thousand bucks for super snazzy controls they would be a little smarter.

I had a similar need in the web module for editing currency values. Here’s where Telerik started to redeem itself. The ASP.NET suite has a numeric text box, as well as the regular masked text box. I didn’t notice the numeric one at first. My eyes kind of glazed over looking through the dozens and dozens of controls in the toolbox. I saw the regular masked text box and figured since it was in the other suite, that it was all they had.

The numeric text box is perfect. It allows free-form input like any text box and then beautifully formats the value into the type of number you want. Now if they could only port that control to the WinForm package…

The DotNetNuke Client API has always seemed mysterious and confusing to me, so much so that I phased it out of a module I wrote a while back in favor of an AJAX web service. But there are certain parts that are useful, namely the ability to store values on the server side for use on the client side, and vice-versa. I recently ran into an issue using it that fortunately was simple to fix. I have a module that will be accessed anonymously, with no user login at all. I was having trouble using the DNN namespace in client script because the browser said it couldn’t find it, which didn’t make any sense at all. Somewhere during the login process all the namespaces get exposed, because once I logged in things worked as expected.

The key was calling DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference in Page_Load of the page where I was trying to use the API. The API documentation mentions that routine, but the context was such that I only expected to need to call it if I was using a version of DNN prior to 4.0 (I had 4.9.0) In any case, it’s fixed and the module development continues apace. My thanks go to Jon Henning, creator of the API, for the tip.