Well, now working with WPF… “How can we have Access/Visual Basic 6/old programs-like indicators for selected and new lines on the data grids?” That is the question, as Shakespeare would say.

I spent a lot of time (and I mean a lot) to answer this question, especially its second part about the new line indicator. And see what I got:

The following style completely defines the selected row indicator and partially (you also need some code behind) deals with the new row indicator:

        <Style TargetType="toolkit:DataGridRowHeader"
               x:Key="DataGridRowHeaderStyle">
            <Setter Property="Content"
                    Value="{Binding Converter={StaticResource cnvNewRowIndicatorConverter}}" />
            <Setter Property="Foreground" Value="RoyalBlue" />
            <Setter Property="FontWeight" Value="Bold" />
            <Setter Property="FontSize" Value="15" />
            <Setter Property="Height" Value="18" />

            <Style.Triggers>
                <Trigger Property="IsRowSelected" Value="True">
                    <Setter Property="Template">
                        <Setter.Value>
                            <ControlTemplate>
                                <Border BorderBrush="Black"
                                        BorderThickness="0,1,0,1"
                                        Margin="0,-1,0,0">
                                <DockPanel Background="Transparent">
                                <Path x:Name="arrow"
                                      StrokeThickness = "1"
                                      Fill            = "RoyalBlue"
                                      Data            = "M 5,13 L 10,8 L 5,3 L 5,13"/>
                                </DockPanel>
                                </Border>
                            </ControlTemplate>
                        </Setter.Value>
                    </Setter>
                </Trigger>
            </Style.Triggers>
        </Style>

For the new line indicator we need to add some code behind:

Public Class NewRowIndicatorConverter

    Implements IValueConverter

    Public Function Convert(ByVal value As Object, _

                            ByVal targetType As System.Type, _

                            ByVal parameter As Object, _

                            ByVal culture As System.Globalization.CultureInfo) As Object _

                            Implements System.Windows.Data.IValueConverter.Convert

        If value Is Nothing Then Return ""

        If value.GetType.FullName = "MS.Internal.NamedObject" Then Return "*"

        Return ""

    End Function

    Public Function ConvertBack(ByVal value As Object, _

                                ByVal targetType As System.Type, _

                                ByVal parameter As Object, _

                                ByVal culture As System.Globalization.CultureInfo) As Object _

                                Implements System.Windows.Data.IValueConverter.ConvertBack

        ' this function is not supposed to be called

        Throw New Exception

    End Function

End Class

What I learned:
1. There is a bug in the WPF toolkit (don’t know whether it’s removed in VS 2010), that sets the binding as TwoWay even if it is explicitly defined as OneWay/OneTime.
2. To avoid the problem one simply needs to specify IsReadOnly=”True” for all expression columns.

PS. Same error occurs if the column is created using calculations in the SELECT statement.

But even more annoying is the fact that, in the debugging mode, VS just keeps cycling through the open files even if I asked it to search in the entire project.

After several years I cannot get used to this feature… or should I say “bug”?

I should definitely add it to my resume along with a Scrambled Eggs Architect and a Funny Architect.

Microsoft keeps inventing crap. What I’m finding now, is a) the documentation is extremely poor. Can anyone show me, for instance, a good example of how to create a simple listview with sortable columns? With some working code?

Never mind, I coded it. However, b) the amazing world of Microsoft is like IBM was 50 years ago: huge and completely disorganized.

There were hundreds of developers in IBM (when IBM DOS then OS came out) who did not know what others were doing. With this small list view control I discovered amazing things:

If you click on the scroll bar, it fires a GridViewColumnHeader.Click event. Oh, don’ tell me it’s by design… I know. One developer designed something that completely did not match what another developer did.

As far as I recall, the most beautiful operating system in the world, PDP-11 RSX-11M, was developed by a team of 20 (including a janitor). Well, when David Cutler moved to Microsoft to develop Windows NT his team was about 200 people… nobody is perfect.

During the history of former VB, its designers had been feeling needs for more and more empty types of data. They invented nulls, empties, empty strings, etc. there was a notion of nothing, ismissing, and other thingies I don’t recall now. With .NET someone said: “Why do we need so many empty things?” And they left pretty much Nothing … and DBNull.

After a while, somebody (else?) realized that this was not enough. How do you define an empty date, for instance? And they invented Nullable.

When I observe this evolution, I see Microsoft as a giant ogre who survived a brain surgery. Its memory is stochastic, its vision of the world is eclectic. It forgets its own experience immediately.

Well, thanks to Microsoft we can earn our little money.

That’s why I decided to share with you some of my observations.

First of all, I am not trying to create any classification or taxonomy here. I realize that there is an entire spectrum between these two categories of workers. Secondly, I don’t want to suggest that all employees (contractors) possess all features described below. However, what is true; people wearing a specific hat (whether an employee’s one or a contractor’s one) with years tend to belong to one end of the spectrum.

Here you go:
1. Contractors sell time, employees sell skills.
2. Contractors are less concerned on what they do compare to employees. A contractor can take an assignment even he does not like it (or even his/her skills don’t perfectly match) and do it. Employees are more often becoming upset if they have to perform a task that they don’t like.
3. Contractors look for a good decision. If they have to make this decision, they tend to come up with quicker solution that is 70% perfect. Employees are not happy with 70 or even 90%, they are looking for perfection.
4. In terms of Herzberg’s theory employees are more interested in motivator factors, and contractors are more interested in the hygiene factors. Employees can work all night on an interesting problem if there is enough pizza around, contractors won’t.
5. Being quite adamant about working on tasks they like, employees hate interruption. They aim for perfection and don’t like multitasking. Contractors can switch their minds easily and minimal context change.
6. Since employees value motivating factors more, they are usually more loyal. Contractors are loyal for a moment.
7. Employees feel very attached to the product of their work. If one can take an example from the IT industry, employees (for example, software developers) consider programs their babies. They feel very upset if anyone treats the babies not right or tries to kill them. Contractors don’t give a damn: projects come, projects go.

Having said all that, I would like to emphasize again that I am using the “contractor” and “employee” words as terms to name the two polar groups (from the behavior point of view) and don’t mean the actual work status.