Thursday, September 24, 2009

Keeping Track Of Non-Modal Dialog Windows

I had a problem.

My problem revolved around a modal dialog window. One which the user base needed to be non-modal.

Now, initially, that sounds like an easy task. It's just a matter of changing the ShowDialog method to a simple Show.

But that's just initially.

The problem comes because this dialog was editing the elements of a list. So, for each page viewed, I could have 1-to-N dialogs, spread out over 1-to-N pages. And I couldn't re-use the dialog windows over and over again.

Of course, even this is not THAT big of an issue--at least until you realize that there is a situation where I do need to re-use a dialog window. Basically whenever a user clicks on an already displayed line item, I need to bring that dialog to the front as opposed to popping a new one up.

And this had to be done without having a handle on the forms, and the control which is spawning these dialogs (and its parents) are not set up as MDI parents.

So, what the provides is the following list of issues:

  • Need to be able to launch N dialogs
  • Those N Dialogs cannot be re-used across list items
  • If a list item is already loaded in a dialog, that dialog just needs to be granted focus
  • No MDI Interface & no time to implement a traditional MDI interface
So, I turned to my trusty friend GOOGLE, and found pretty much zip. Apparently, most non-modal dialogs are either a singleton type thing or they're spawned and forgotten. Which for the most part, that's the case. I can see that the constraints that I'm working under are not common.

So, after thinking some more, I create a new project in Visual Studio to allow me to play with things. I tried grabbing the HWND object for my dialog but that was obscenely bulky and prone to errors.

Then I had the grand idea of keeping a list of these dialog windows in my control. That way I would have a handle for all of them.

So I tried it. I launched three different list item elements, all of them popped up. When I went back to the main form, and clicked one of those list item elements again, the correct dialog gained focus. I was scrubbing my hands and getting ready to do that "I control the world and am a genius" cackle.

But I had one last test, which is I closed one of the dialog and then clicked its corresponding list item.

And got nothing. Zilch.

After a quick breakpoint add, I discovered that those closed dialogs still existed in my list.

So, I proceed to bang my head on my desk.

Then I went and retreived my boss, and presented the problem to him, hoping he'd have some brilliant idea. Which he failed to grasp the problem until I reminded him that whole "there's no MDI" thing, at which point he got this kind of sick/amazed/amused look and basically told me I should have fun trying to solve this one.

Which is when I remembered events.

Oh those beautiful, wonderful things called events.

What had slipped my mind is that an event is raised to the window and then sent down the control chain until it finds a control that basically says "I'm supposed to handle that!"

So I go into my code, and to the CLOSING event of the dialog I add a new event that I raised. One that is consumed by my calling class.

When I handle said event, I know that I can remove the associated dialog from my list of open dialogs.

And wouldn't you know it, it all works just about perfectly.

Thursday, September 10, 2009

CAPTCHA Usability

Here's a secret, I despise CAPTCHA's. I hate them. I think they are one of the most user-unfriendly form elements in existence.

Most of the time, I can barely read them.

I understand their purpose, and I know why they exist. But that doesn't mean that I actually like the things, and it definitely doesn't mean that I like entering data into them.

But then there's the ones that I find are actively HOSTILE to the end user.

After all, the usage pattern for these evil things is fairly standard, everyone knows what to do:

  1. Squint and try and make out the relevant letters
  2. Type those letters in as they are displayed
  3. Press the submit icon/button/dongle/blood letting device
This process has become ingrained. It's what we expect.

Which is where I get to that hostile statement above.

I found one of these captchas, and entered the data, and it came back invalid.

So I entered it again, with the same results.

And again, and again.

Finally, I was starting to want to smack the website's author when I noticed something.

Instructions.

Who puts instructions on a captcha I thought to myself as I began to read.

For posterity, I made a screen shot. And in case you were wondering, this is the context of that block of text:
Confirmation code READ THIS INSTRUCTION CAREFULLY: *
Type a lower-case "w" into the box and then follow it with the code exactly as you see it. The code is case sensitive and zero has a diagonal line through it. The initial "w" is necessary - the system will reject your registration if you do not include it
Yes, they REQUIRE you to type a lower-case "w" as the first letter of the field.

Why? As far as I know it's just to annoy anyone trying to register for their site.

My ultimate thought: poor, poor design.

Wednesday, September 9, 2009

More Patent Shenanigans...

Apparently, a company has patented cross-communication between applets of an application utilizing a shared data store with both relational and objective data.

What that means is that someone patented the concept of including those Apps in Facebook and Twitter and any other application which uses plug-ins (including FireFox and Visual Studio) and a data store and a global network.

What is sad is that they've convinced a judge that there is reason to force Facebook to provide them the ability to review Facebook's source code.

Yes, a United States Federal judge has told a company that they must divulge trade, copyrighted secrets to a competitor in order for that competitor to successfully sue them.

All because Leader Technologies patented the concept of plug-in software.

I'm sickened by this, and see it as yet another reason why software patents need to disappear forever.

Of course if I was Facebook, I would facilitate the review of my source code by providing it in hard copy format.

After all, Facebook wouldn't want to step on anyone's toes by possibly using infringing software that features such niceties as the "Find" function or source code formatting.

Tuesday, September 8, 2009

Software Patents Are Insane

I'm a Software Engineer. I design and build software systems. It's what I do. Even when I'm off work, I design and build software systems.

And I hate software patents.

I firmly believe that they are one of (if not THE) worst idea that has ever been inflicted upon my industry and craft.

Case in point, have you ever typed into the address bar of your web-browser and gone to a website without having to type in the entire domain name? For example, I'll type in "Facebook" and be taken to http://www.facebook.com.

It's a reasonable action on the part of the browser and it makes sense. Additionally, it's functionality that's been around for many, many years now.

Which of course means that it is now patented.

TechCrunch has an article about an Israeli company that has received a new patent for that behavior (and for the "I'm Feeling Lucky" button that's been on Google's homepage for probably a decade now).

What this means is that browsers and search engines are either going to have to change the functionality that people expect and use, or pay a hefty sum in order to keep the functionality.

This is insane.

As a recent CATO article described, imagine if a certain type of plot twist was patented. Imagine, never again being able to read about someone suddenly being alive again. Never getting to see that type of literary device used in movies, comics, books or television shows. Unless the company using it paid someone a hefty dollop of dollars.

Sounds insane doesn't it?

Yet, we're perfectly accepting of the insanity in the software field?

No. Or at least, I think it's insane and pray that the upcoming Supreme Court case overturns the ability to patent software.

After all, we all need to remember that software systems are not inventions.

They are copyrightable works of art.

Friday, September 4, 2009

Duplicate Image Resources in WPF

I'm currently in the final stages of a large project. We're talking hundreds upon hundreds of man-hours, thousands upon thousands of lines of code, and even a good hundred or so image resources.

All of this, spread over 15 projects. These projects did everything from standard data access (to the local data store) to administration data access (via the central data repository) to installation and installation custom actions, in addition to the core and supporting functionality of the application itself.

It was a standard system, I had the controlling application, and a bunch of supporting, functionally-grouped class libraries.

The thing is that I built this thing working in those functional groups, and it was rare for a library to talk to another library directly. Sure, I had a library with shared functional classes and then the data layer, but in general, those units worked by themselves, and I built them separately from one another.

Which means that I had a lot of images duplicated across the project.

In fact, the Installer (a MSI file) was 15,283KB.

Which isn't that big considering how large this application is, but it's still a big file considering our distribution method is the internet.

So, I started looking at all those images, and realized something.

I didn't need them all.

Because I had a library that was built before all the other libraries, and more importantly was built as an attached library to them all, I could move all those images to that library, meaning it would only be a single place for me to call them from.

By the time I had finished moving most of the images into a single DLL (there were some images in the Reporting section that I had to leave in that library) I had the MSI's size down to 11,786KB.

And the coding involved is simple. There are in fact two ways to approach this.

The first is to modify the Image's SOURCE attribute. The usual way to do this is to use this

Source="/MyDLL;component/Folder/Image.png"
and then modify it to
Source="/MyOtherDll;component/Folder/Image.png"
Not that hard.

The second way is a bit more involved working, but is probably a better solution in the long run, especially where ease of re-usability and standardization is concerned. And that's to define it into a style for your image.

In this, you'd create a new style for an image, providing it little details such as the Source URI and then use that as a DynamicResource in your various DLLS. That would look like this:
< style="{DynamicResource UndoImage}">
But the fundamental thing to remember is that you don't need those images duplicated in every DLL that you're building for your project.

Blog Widget by LinkWithin