Intermittent bug. Order of attribute does matter in WPF


When I was developing some XAML page, I encountered one situation where I experienced some intermittent bug from WPF. Some of my buttons will go disabled at times even if the CommandParameter bind to a buttons command has proper value to enable button. Below is the solution for this.

How did I fix it:

For example, you might write something like this for your buttons command binding to the corresponding view model:

<button command="{Binding Path=Command}" commandparameter="{Binding Path=PathTo}">Test</button>

Here in this example the command expects a non-null parameter as the CommandParameter. In WPF, some properties have built-in dependency on other properties. WPF will process the attribute in its order. If the properties are not placed based on their priority, then there is no other ways to express such a dependency. In such cases order becomes important.

In most of the situation, this won’t be a problem. Because in the process of creating the control, focus is shifted to the window that contains it, you will fire enough checks that the command will be evaluated multiple times and the button will get enabled. But if you are creating the control on another window or control that does not contain the focus, the order of the above code will result in a disabled button until you shift focus.

To correct this problem, respect the order of attributes in XAML. If you just swap the attributes so that you bind the CommandParameter first, then the Command will have the correct parameter when it gets evaluated.

<button commandparameter="{Binding Path= PathTo }" command="{Binding Path=Command}"> Test</button>

In WPF attributes have priorities and we have to sort attributes based on their priority. To sort it manually is very difficult as you have to remember the order of priority. Here what I would recommend is to use some tool which sorts attributes in its order based on its priority. XAMLStyler is one such tool. By using such a tool we can get rid of any possibility of such errors. The above mentioned example is just an example. There are many other occasions where we need to take care of the priority of the attributes.

Parquet file experiments, findings and recommendations

Parquet is a binary file format designed with big data in mind where we must access data frequently and efficiently. The way it stores file on the disk is also different from other file formats. It is a column-based data file. And in reality it uses both row based and column based approach to bring the best of both worlds. The data is encoded on disk which ensures that the size remains small compared to actual data and is then compressed where the file is scanned as whole and cut out redundant parts. The query/read speed is dramatically fast when compared to other file formats. Nested data is handled efficiently which is quite cumbersome in other file format to achieve. Doesn’t require to parse the entire file to find data due to its way of storing data. This makes it efficient in reading data. Works quite efficiently with data processing frameworks. Automatically stores schema information. SQL querying is possible with this file format using Continue reading

Libish Varghese Jacob

Libish Varghese JacobI am currently working as a lead engineer in one of the leading wind turbine manufacturing firm. I have wide range of interests and getting my hands dirty in technology is one among them. I use this platform primarily as my knowledge base. I also use this platform to share my experience and experiments so that it might help someone who is walking the way I already did. The suggestions expressed here are the best to my knowledge at the time of writing and this may not necessarily be the best possible solution. I would pretty much appreciate if you could comment on it to bring into my notice on what could have been done better.