Error Two-way binding requires Path or XPath

Introduction

Worried over this exception? This happens when you haven’t set the Path= on binding. By default WPF binding will take the Path= part by default. But on controls which have a two way binding by default, this seems not to be working. You may have to set it explicitly. But in certain scenarios, you may be binding the value in a DataTemplate, for example,

 <DataTemplate x:Key="BoolValueTemplate">
    <DockPanel>
       <RadioButton IsChecked="{Binding }" GroupName="IsSelectedGroup">
       </RadioButton>
       <RadioButton IsChecked="{Binding Converter={StaticResource InvertedValueConverter}}" GroupName="IsSelectedGroup">
       </RadioButton>
    </DockPanel>
 </DataTemplate>

Here you prefer the control to take the default value which is set by the ContentControl or TemplateParent. If you try to bind it like this, you will get an exception which says like, Two-way binding requires Path or XPath. To fix this, you have to specify the path like as shown below.

Path=.
<DataTemplate x:Key="BoolValueTemplate">
    <DockPanel>
       <RadioButton IsChecked="{Binding Path=.}" GroupName="IsSelectedGroup">
       </RadioButton>
       <RadioButton IsChecked="{Binding Path=. , Converter={StaticResource InvertedValueConverter}}" GroupName="IsSelectedGroup">
       </RadioButton>
     </DockPanel>
</DataTemplate>

Now here this cannot be called as a bug, but it’s a feature which blocks developers from adding a binding which they assume to be a one way binding. Those controls which take two-way binding by default will expect developers to explicitly specify Path.

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.