Winfrom and WPF (3) controls -- checkedlistbox

I once wrote a filtering demo with a list selection control:

This is just a full selection function.
I used to think that there should be a more elegant way to implement the full-selection function. Even though I still haven't found it, sometimes people will tell you not to be too entangled in a problem, as long as the function is implementedProgramThis is often not the case.
When I started to use winform to implement this function again, I found that I still had to use the original method, and there was no better solution to do this. This is because winform is too rigid to implement customization simply like WPF.
This demo is for this seriesArticleIn the first WPF demo, I try to make it easy to understand and only show some questions about the rewrite template.

Original article address:Http://nanqi.info/blog/2013/03/31/winform-wpf-3/

Implementation Scheme in winform

CodeAlmost the same as that of the filtered demo, the only difference is that I don't have to control the choice of checkedbox (autocheck) by myself. At the same time, I also found that I did nothing wrong at the time, because if the checkstate attribute of the checkedbox is indeterminate and you want to select it again, you have to do this (in fact, it also reflects from the side, not just implement the excess, and wrong ).
I still use the itemcheck event of checkedlistbox. The Code is as follows:

 1   Private   Void Chbxlist_itemcheck ( Object  Sender, itemcheckeventargs E)  2   {  3       This . Chbxall. checkedchanged-= This  . Chbxall_checkedchanged;  4       If (E. newvalue = checkstate. Checked & chbxlist. checkeditems. Count + 1 > = Chbxlist. Items. Count)  5  {  6 Chbxall. checkstate = Checkstate. checked;  7   }  8       Else   If (E. newvalue = checkstate. Unchecked & chbxlist. checkeditems. Count- 1 <= 0  )  9   {  10 Chbxall. checkstate =Checkstate. unchecked;  11   }  12       Else  13   {  14 Chbxall. checkstate = Checkstate. indeterminate;  15   }  16       This . Chbxall. checkedchanged + = This  . Chbxall_checkedchanged; 17 }

 

I have been worried about the-= and + = problems. This time I suddenly remembered why I used the itemcheck event instead of selectedindexchanged. I tried it this time, I thought I had discovered the optimizations in the original code, and finally I knew why I didn't need them.
The same problem as I added a checkbox column when I used the datagridview: Double-click may cause a problem.
If you are interested, you can try it. I will not demonstrate it here. There are many similar problems, including winform and WPF, but they are often found in WPF, it can be easily solved using other methods, but it is not that easy to solve in winform.

Implement a checkedlistbox in WPF

WPF does not have such a control, but almost people who have used WPF several times can implement such a control, that is, the control becomes the way in winform, you can simply change the style here.
In the XAML of WPF, I still have a lot of questions I have not understood yet. I am very familiar with a person who just came into contact with WPF and saw a lot of fear in the XAML, this is also the first time in this series of articles to use WPF. I think it is still necessary to address some basic problems (but not the basis ).
First, when you get the source code, you will find that I use ListBox for implementation. There are many options, so you don't have to worry about it here. You will find that I have written two copies of this style, in addition, a resource is stored in a resourcedictionary and stored in the app. it is introduced in XAML.
In fact, this method is similar to that with a key value, but there are many differences. If you put this example in a project, it is obviously wrong to do not include a key value, because it is impossible to make all listboxes A checkedlistbox, but I hate to see many attributes on a control. At least when it is placed on the interface, it can be less or less, at least there is no problem in this example. I finally put it on the interface like this:

 1  <  ListBox  Name  = "Checklistbox"  2   Canvas. Left  = "10"  3   Canvas. Top  = "29"  4   Width  = "256"  5   Height  = "191"  6  Itemssource  ="  {Staticresource itemsdata}  "  7   Selectionchanged  = "Checklistbox_selectionchanged"  8   Selectionmode  = "Multiple"   /> 

 

Next, let's talk about why I wrote two styles. First, let's look at the first style:

 1   <  Style Targettype  ="  {X: Type listboxitem}  "  >  2       <  Setter  Property  = "Template"  >  3           <  Setter. Value  >  4               < Controltemplate  Targettype  ="  {X: Type listboxitem}  "  >  5                   <  Checkbox  Margin  ="  {Templatebinding margin}  "  6   Content  =" {Templatebinding content}  "  7   Contenttemplate  ="  {Templatebinding contenttemplate}  "  8   Contenttemplateselector  ="  {Templatebinding contenttemplateselector}  "  9   Focusvisualstyle ="  {Templatebinding focusvisualstyle}  "  10   Ischecked  ="  {Binding isselected,  11   Relativesource = {relativesource templatedparent }}  "   />  12               </  Controltemplate  > 13           </  Setter. Value  >  14       </  Setter  >  15   </  Style  > 

 

If you think this code is very simple, you may know a lot about WPF, or you may not know why to use templatebinding like me.
If WPF is too flexible, it will allow tens of millions of writing methods to implement a function. Many times, when you find that a style is not correct, it is often difficult to solve the problem.
Templatebinding can be used in either of the following situations (self-summary ):

1. Normal binding
2. It is not written to the template, leaving extensions for the outside

The first point is not mentioned here. If the content above is not bound here, you will find that there is only one check box without text.
For the second point, there is a reuse problem here. The values in the template will not change no matter what the outside world is set. In this way, a function is permanently disabled. If there is no absolute reason, do not do this. To illustrate, the second style is shown here:

 1   <  Style  Targettype  ="  {X: Type ListBox}  "  >  2       <  Setter  Property  = "Itemcontainerstyle"  > 3           <  Setter. Value  >  4               <  Style  Basedon  ="  {Staticresource {X: Type listboxitem }}  "  Targettype  ="  {X: Type listboxitem}  "  >  5                  <  Setter  Property  = "Margin"  Value  = "2, 2, 0, 0"   />  6               </  Style  >  7           </  Setter. Value  >  8       </ Setter  >  9   </  Style  > 

 

The main function of the second style is to set the margin attribute of listboxitem, but why didn't this value be directly written in the first style.
At this time, some people will say that I can rewrite the template on the outside to achieve the same, yes, the same, but why do I have to say this? It's better than it is, it's easy to know at a glance.

Implementation Scheme in WPF

This is only for comparison, using the full winform event-driven method.
Of course, this is not necessary in WPF. I will use the WPF method in the next section to gradually implement this function. Here I will first look at the first problems that occur during the migration from winform to WPF, find events.
In this example, you can find the corresponding events. If you change to another function, you may find that many events in winform do not exist in WPF, when the problem is exposed, you should consider the implementation method in the system learning WPF, instead of continuing to implement it in your own way.
Let's take a look at the idea of using winform directly in WPF.

 1   Private   Void Checklistbox_selectionchanged ( Object  Sender, selectionchangedeventargs E)  2   {  3 Chbxall. ischecked = checklistbox. selecteditems. Count = 0 ? False  :  4 Checklistbox. selecteditems. Count = checklistbox. Items. Count? ( Bool ?) True : Null  ; 5   }  6   Private   Void Chbxall_checked ( Object  Sender, routedeventargs E)  7   {  8   Checklistbox. selectall ();  9   }  10   Private   Void Chbxall_unchecked (Object  Sender, routedeventargs E)  11   {  12   Checklistbox. unselectall ();  13 }

 

You will find that it seems to be simpler than winform.
However, you can know that if WPF is to truly separate pages from logic, there is no logic code in the background, and there must be only some code displayed on the control interface.
Of course, we do not need to do anything too thoroughly, and it is not a proper development method to force code writing in the background, and the example is written here, I just want to express one thing, that is, there are too many ways to implement a function in WPF. I hope you will not explore better implementation methods because of implementation, sometimes this is also a learning of WPF design.

 Source Code address:Https://github.com/NanQi/demo/tree/master/SelectDemo