.NET Junkie’s Blog

I’m coming with a very recommendable blog for all those addicts to the most tasty programming.

http://www.cuttingedge.it/blogs/steven/index.php

This guy not only talks about coding properly, with a solid foundation, but he also have a serious knowledge about .NET and is very passionate. He defines himself as being diagnosed “a workaholic”. What more can I say? Great, Steven.

Follow him in Twitter! @dot_NET_Junkie

Glass for .NET, Drag&Drop demo :)

I’ve just published a download ready to compile and run.

Set the Glass.Test as the startup project and GO!

You will see the screen splitted in 2 parts. The first one contains 2 different sources. One is a Panel. The other is an ItemsControl.

You can either drag a control from the Panel (a Canvas) or an item from the ItemsControl (ListBox).

If you see the source code, you will notice it can be applied to ItemsControls or Panels.

Every control that will be part of a Drag&Drop operation will have the behavior. It can acts as a Drag Source, Drop Target or both.

I think the sample is self-explanatory. Go download it and try! If you have any question, let me know

DOWNLOAD Glass.Basics with the Demo included.

http://glassnet.codeplex.com/releases/view/103503

If you have any question, use the Discussions here:

http://glassnet.codeplex.com/discussions

The Insufficiency of SCRUM

A great post I’ve found that it’s worth reading.

http://billschofield.typepad.com/my_weblog/2009/08/the-insufficiency-of-scrum.html

Pretty clarifying, uh?

If that is not clear enough, read John Sonmez’s thoughts on Agile and Scrum in his fantastic article “Where is Agile now?”

When a methodology that is presumably agile turns clunky.

Developing  under SCRUM often reminds me of a game call World Of Goo when you build a tower of elastic creatures: The Goos.

At the very beginning, everything is agile and quick, putting Goos at the base like mad, barely thinking if they’re located in the right place. It seems it’s not very important while they give some support on the ground.

When the towers is getting some height, it starts swaying from one side to the other. Placing Goos is more difficult each time. You’ve got to thinking it twice before you put the next one.

That crazy pace starts to slow down to crawl and the most of time it’s spent trying to fix the structure to make it more stable.

But, normally, it’s too late. Wind blows the tower, and its structure is lacking robustness. Eventually, sometimes without touching anything, the tower collapses on its base and bends over itself. It falls through spectacularly.

Tower fucked up. Oh boy!

Esto sí que es una buena Reflection!

¡No sé para qué escribo en inglés si no me lee ni Panete!

XD

Handling selected items in a parent. Part 2.

Last time I tried to put you down to the problem: you have a container and some children. We wanted to handle the selection of items.

Until now we had to decide who will be the one that is in charge of setting the IsSelected property of each child. At first glance, we can see that the child itself is the Information Expert in which we can delegate the responsibility. After all, the children carry the  IsSelected property!

Well, I think it’s true, but that makes the design unnecessarily complex.

Why?

Imagine a Single selection mode! Just like ListBoxes have. Just one item can be selected.

I gave you a hint in the last post. It works as you should expect: Each click in a child selects it, but it also makes the previous children to be unselected.

“Wow, boy, it sounds pretty simple!”

I prepared you for the answer: it’s not the child that controls its IsSelected property… it’s the PARENT! In my opinion, it’s the only that can observe the changes and control the flow of events. If a child is clicked, the parent must know. Why? Because the it can decide if the change is allowed of not.

What way, you can even have some selection modes. For example, you can have a selection mode that toggles selection when a child when it’s clicked, or one in which you always add items.

In other words, it gives you a lot of variants to choose.

This is what I finally chose in my personal designer and I think it’s the right decision. What do you think? would you have solved the situation like me? C’MON tell me.

Don’t leave my this way!

UPDATE. My Glass library contains an improved version of this behavior. Take a look at it!

Aha! So you just discovered that users tend to break your applications typing everything you could imagine. Validation in Hell!

Imagine you have some information that has to be filled in. For example, this Window tell you to enter a value between 1 and 5.

It may be not obvious to the user that information is extremely important. So you cannot leave it in an invalid state.

Boy, those mandatory fields must be valid before you go away!

But, how do you keep they into the TextBox? The user types “2000” and suddenly, they change the focus to the Dummy text box.

The required TextBox will show its value is invalid, but maybe the user is happy with that red TextBox and starts to touching here and there with something that is wrong. This can be, of course, perfectly acceptable, but sometimes the information you request just cannot be left in an invalid state.

That is why I made this Interaction Behavior. KeepFocusOnErrorBehavior.

If you attach it to any TextBoxBase (like TextBox), you will notice it will not let you change the focus to another control while it doesn’t pass the validation. Example:

As you can see, this behavior is attached to the TextBox and its ErrorCommand is set to a Command (in a View Model). This command makes it even better, because you can, for example, bind a Command that shows a message indicating that you’re not allowed to go anywhere before entering correct input.

I hope you like it

Here is the code:

public class KeepFocusOnErrorBehavior : Behavior<TextBoxBase> {
        protected override void OnAttached() {

            AssociatedObject.PreviewLostKeyboardFocus += AssociatedObjectOnPreviewLostKeyboardFocus;
            base.OnAttached();

        }

        private void AssociatedObjectOnPreviewLostKeyboardFocus(object sender, KeyboardFocusChangedEventArgs keyboardFocusChangedEventArgs) {

            var textBindingExpression = AssociatedObject.GetBindingExpression(TextBox.TextProperty);

            // Forces to update the binding. As we are preventing the focus to be lost, its binding never updates and never recovers from a previous error.
            textBindingExpression.UpdateSource();

            var value = Validation.GetHasError(AssociatedObject);
            if (value) {
                keyboardFocusChangedEventArgs.Handled = true;
                ExecuteErrorCommandIfCanExecute();
            }
        }

        private void ExecuteErrorCommandIfCanExecute() {
            if (ErrorCommand != null) {
                if (ErrorCommand.CanExecute(ErrorCommandParameter))
                    ErrorCommand.Execute(ErrorCommandParameter);
            }
        }

        #region ShowErrorMessageCommand
        public static readonly DependencyProperty ErrorCommandProperty =
          DependencyProperty.Register("ErrorCommand", typeof(ICommand), typeof(KeepFocusOnErrorBehavior),
            new FrameworkPropertyMetadata((ICommand)null));

        public ICommand ErrorCommand {
            get { return (ICommand)GetValue(ErrorCommandProperty); }
            set { SetValue(ErrorCommandProperty, value); }
        }

        #endregion

        #region ErrorCommandParameter
        public static readonly DependencyProperty ErrorCommandParameterProperty =
          DependencyProperty.Register("ErrorCommandParameter", typeof(object), typeof(KeepFocusOnErrorBehavior),
            new FrameworkPropertyMetadata((object)null));

        public object ErrorCommandParameter {
            get { return (object)GetValue(ErrorCommandParameterProperty); }
            set { SetValue(ErrorCommandParameterProperty, value); }
        }

        #endregion

    }

Handling selected items in a parent. Part 1.

When trying to make a good design you face situations in which you have to take a difficult decision that will easily affect the whole complexity of any  further development.

“Design concerns”. That is how I call them. And some are really nasty!

From now on, I will share the troubles I stumble upon. Because not only will I annotate my current design concerns for future self-reference, but also let people participate with comments.

One of my current design issues I ran into was the relationship that a parent and its children keep in several ways, the most important of them being the selection of children.

Let’s imagine this situation:

We’ve got a designer surface with some items. This surface is the parent of every other items inside.  Its children are Mario, a Button that says “Hola tío” (Hello dude), and the pretty obvious TextBox “This is my text”.

Knowing that it’s a designer with some elements into it, the user will expect some specific behavior. The most important are dragging and resizing.

Now the user sees Mario into a blue rectangle, remembers the times when they jumped all the way breaking blocks and decides “I will drag Mario!”. OK, the user expects Mario to be dragged around the surface.

STOP. Before moving anything we have to know what we want to move. How will we know that we have to move Mario?

ANSWER: Oh yes. In order to move him, we will have to select it first. So we will have some items that will be selected. Selected items! A common concept, uh?

OK, that sounds good.

Selected items, but what selected items? We need to select some of the children.

HOW?

Clicking on the desired item should be enough. It’s the standard behavior. Isn’t it? So we decided that we will get the clicks on each item in order to know it has been selected to do something (dragging, for example).

Let’s go!

1. Create a boolean IsSelected property, for the class that will represent the item.
2. Add an event handler to each child to capture the mouse click and change its state.
3. On click, turn the IsSelected to true.
4. Give the element the proper appearance when it’s selected.

Pretty good.

Now, click every item and observe the goodness we achieved!

OK, you may have noticed that not only the items are selected individually, but also they is a concept of group in the capture. Just ignore it it’s part of my Glass library, currently being under development.

The fact is that we have a bunch of selected items that cannot be unselected. “Woahh, simple!” you will say. Just toggle IsSelected when clicking each time.

IsSelected = !ISelected;

Neat. Now you have more options. It’s alright. You win. But this is still far from being usable.

1. First of all, when you have selected something and you want to drag it, each click will change the selection state.
2. It’s really annoying to select items because most of times you will only want to select a single item: the one you just clicked. The others are discarded and only the newest should be the selected one.
   I know, I know! there will be many times in which you will want to select multiple items. We definitely will have to handle those situations.

You may ask:

– Couldn’t I just intercept clicks on an item and then iterate through the rest of children in order to unselect them? In other words: each time I click one, I can unselect the others.

WRONG! If you click an item and this item and you make it responsible for changing the state of its neighbors, you’re giving it a really high responsibility. How could it be aware of each other item? That sounds like we’re breaking some very important rule.

If we have to interact with other neighbors but we’re just a little modest item that cannot say the others what to do (we don’t mind about them), who could help us to unselect the rest of the items if I, as a child, receive a click and I want to change my state?

To be continued…

Painless Drag&Drop en WPF

Si te duele el ojal de tanto OnDragCompleted in OnDragPiticanDeMore, lo suyo es que apliques un Behavior, esas bendiciones de Dios en el terreno de las interfaces de usuario.

Aquí tienes un ejemplo de lo maravillosa que puede ser la vida si te lo montas con un poco de cabecilla en vez de meter código guarrero en el code-behind.

ENCAPSULAAA, ENCAPSULAAA, EN CAP SU LACIÓN!

http://codeblitz.wordpress.com/2009/06/26/wpf-itemscontrol-drag-drop-behavior/