As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know the whole point behind it, but at the end of the day, the only thing provided is a clean code, am I right?
The problem:
To perform a data bind, you'll have to do some stuff in code behind (set a dependency property), which sometimes may be clear, and sometimes not. Then you'll have to find out how the hell to access the values from your dependency property (the object you're trying to use). Then, ok, you spent some time deciding that you'll access it through ElementName or Ancestor or whatever (because you'll have to find out by yourself how this works, Microsoft's documentation on that is pretty lame, it's not straight forward).
Then, ok, you spent some time and now your data binding is working, except that is not. Because the class of the object you're binding to must implement INotifyPropertyChanged. Just that. Or not, because you'll have to assure that an event (OnPropertyChanged) must be triggered in order to update the values on your interface ... by sending as an argument a string containing THE NAME OF THE EFFING PROPERTY. That's as lame as JSF's way to access values (obliging the developer to have getters and setters exactly the way they want). An also, if you're building your software in layers, forget, you'll have to implement INotifyPropertyChange every-effing-where.
I'm writing this because I want to know if:
I'm doing everything wrong and that's why I don't get the point.
Is there a better solution to deal with this kind of stuff?
Am I the only one who thinks that it doesn't make any sense?
Before anyone asks: Yes, I understand that the event makes "some" sense, because there must be a way to know that the object changed. But I don't see much difference of using that or just calling an Update method every time I do anything in the interface. I hope you guys don't think I'm stupid for posting this ... I'm a pretty new programmer (3 years since my graduation began and 2 years working experience), but the lack of a better way to do that kind of stuff doesn't look like, for instance, Microsoft's ASP.NET MVC, which just works magically. I'm not asking for everything to be easy, just asking for a better documentation, and, I don't know, an easier (by easier I mean more straight-forward) way to do something that you're supposed to do when using the framework, something that is considered elegant.
I like turtles. I also love data binding. I recommend reading up on the MVVM pattern... it uses data binding to make it easy for you to run unit tests and keep your code organized/clean. Be sure to look at how the "DataContext" property is used in MVVM.
P.S. I don't think that using the name of the effing property in OnNotifyProperty is lame at all. What else would you use without adding dependencies or unneeded complexity?
P.P.S. Clean code is a very big effing deal.
That it is hard to learn does not change that it is a powerful technique, this covers about most of your rant.
You can resolve the property name from a lambda expression if you have an aversion to strings. The code for an extension method that does that is floating around somewhere on SO.
If you don't want to implement it everywhere implement it in one base-class.
If you want magic use an MVVM framework that does that. Caliburn for example hooks up controls and methods/properties without writing any binding code.
Bindings decouple components.
Related
two-way binding feature in angular is so popular, and according to angular community it is good when compared with one-way binding.
And there are lots of simple examples to explain how it works.
But my question is where does we use that feature in real applications.
- One example is using with input boxes, other than that is there any good uses of it?
Two way binding as a default wasn't wise because it creates perf issues (~2000 watchers and your app can go bad fast). It led to the introduction of {{::}} binding syntax (bind once syntax) in Angular 1. Overall I can't see where I agree that default two way binding is said to be a good thing by any knowledgeable Angular dev.
I can tell you for a fact, having written an application that displayed many lists of different kinds of objects simultaneously, that default two way binding was a mistake. It created far too many persistent watchers. The community overall seems to strongly agree.
So what you suggest here is correct; there are uses for two way binding. But those needs should be seen as few and far between. And even then, you could probably get around the need for it at all with a little thinking.
For me, two way binding is primarily useful for input fields. But the mechanism is most definitely downplayed now, it should be used sparingly.
Well, when you bind a label with a $scope variable, though the binding is two-way (by definition) it is only relevant in the direction JS -> HTML.
A two-way binding is only fully exploited in cases where the value can also be changed by the user, meaning any type of INPUT component (textbox, dropdown, checkbox, etc.).
One trivial (though one-directional) example is when you have a page that can be displayed in many languages. You would deploy $scope variable all over, and assign to them strings in the current language.
When the user switches language, the simple assignment of the new strings to the corresponding variable will yield the screen to be automatically update to the new language.
Me and my colleagues are investigating how to replace 3rd party WinForms controlls by our new UI controls in our large legacy codebase. Practically we would like to replace the 3rd party controlls in the inheritance chain. The 3rd party controlls are used dozens of places by subclassing the 3rd party UI controlls. We d like to perform this change as safety as possible, with minimal code change all over the solution. Do you have any experience how to start? Obviously the inheritance means strong coupling here, so i d like to find the less painful solution here.
Is the "branch by abstraction" concept applicable here?
This is a pretty subjective decision based on your team's understanding of the code base as well as workflow. The bright side is that you've already subclassed all the controls, so you've already done the tedious work of being able to provide whatever properties the code is looking for to compile.
Given that this is WinForms, this should be much more straightforward, since the control sizes and locations are set on the Control level. You need to worry about mapping properties/methods that exist in the old vendor's controls to your new controls and not as much about form layout. This might be straightforward for some controls and more complex for others (i.e. grids).
The biggest roadblock IMO is going to be handling the current design-time serialized logic in InitializeComponent. If you've created a property to map from old -> new, you're going to have to be careful that when the designer re-serializes everything after you open the form and modify something, you might not want to serialize both the old property and the new. As an example:
Old Vendor
this.myOldComponent.Data = this.dataSource;
New Vendor
this.myNewComponent.DataSource = this.dataSource;
In this case, you may consider creating a new property called Data on your subclassed new component so that the old code works without changing anything. Let's say you open the form in the designed and move the grid a few pixels, causing the designer to serialize the data. You might now have:
this.myNewComponent.Data = this.dataSource;
this.myNewComponent.DataSource = this.dataSource;
You can prevent serialization with attributes (good discussion on it in this SO question, but this is just an example of something you might hit.
I don't think there's really a pattern here to follow, unless you mean on the source control level, in which case I would say to absolutely create a new branch apart from your regular development one; who knows what kinds of roadblocks you may hit and you'd want to shelve your work for a bit.
Ultimately, you may decide that it's just best to suck it up and rip out the old components and put in the new, but as mentioned this is very subjective. It's situations like this that make me really love WPF and the MVVM model, since you could entirely rip out the UI and keep the business logic intact.
I’ve been having issues with the TreeView in WPF. This control makes it very hard to access the TreeViewItems it’s showing.
On several occasions I have worked around the need to access a TreeViewItem, for example I’ve accepted the fact that I’m not supposed to access a node’s parent via TreeView (and am supposed to instead keep track of the parent myself). I’ve been doing this for two reasons: first, it’s obviously extremely hard to get at the TreeViewItems, and secondly, I’ve been told that it’s hard because I’m not supposed to need them if I do things right.
However, this time I really see no way around this.
Basically, all I want is, given one of my viewmodel instances, scroll the tree view to it. This is trivial if I could just get the corresponding TreeViewItem.
Am I doing things wrong again by trying to get at the TreeViewItem, or would that be the right approach?
Take a look at Simplifying the WPF TreeView by Using the ViewModel Pattern article by Josh Smith. I hope it helps.
Admittedly this is not straightforward but you can probably still do this while keeping a separation which does not require you to access the TreeViewItems knowingly. The essence in WPF is binding as already noted by Kent Boogaart in your other question, here however you need to somehow deal with events. Your view-model needs to fire a BringIntoView event of its own while the view needs to react.
The easiest method might be to add a EventSetter on Loaded to make the TreeViewItems subscribe to said event on their DataContext which should be your view-model (if it isn't you can wait for DataContextChanged).
No, I dont see in what way accessing the items of a treeview is wrong.
I think the difficulties you are encountering are because you aren't seeing the treeview as it should be.
A leaf has a parent, but no children.
A node can have a parent, and can have children.
A node without a parent is a root.
Based on these principles (SourceMaking Composite pattern) you should be able to do whatever you want using recursivity. (in both XAML and code)
I’ve come to the conclusion that it can’t be altogether wrong. The first piece of evidence comes from Bea Stollnitz’s post about ListView: if one of the WPF developers explains how this might be done, it can’t be that wrong.
The other piece of evidence comes from this highly-voted question/answer: MVVM madness. MVVM undoubtedly has its benefits, but sometimes the cost of following MVVM is so high that it’s just silly following through with it, especially in a small one-man application. Do you really want to expose IsSelected and IsExpanded the way you’re supposed to?
As a result, I felt justified to try and figure out how to expose the TreeViewItem corresponding to an item with less effort from the developer, under the assumption that they will never need the more advanced features that resulted in TreeViewItems being this hard to access (like displaying the same ViewModels in multiple different controls... how often have you needed that!...)
I posted the result of this effort as an answer on another question.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am looking for any best practices or guidelines regarding animation in WPF. Especially information regarding performance considerations.
After I have gained a bit more experience in this field since I have asked the question, I will answer this myself. My experience comes from working on the WPF mind mapping application NovaMind - We have done lots of animations lately for our Presenter feature in NovaMind Platinum :-)
The MSDN section on Optimizing WPF Application Performance has some useful information about general considerations when writing WPF apps:
http://msdn.microsoft.com/en-us/library/aa970683.aspx
Here are some bits which I have found especially useful and are related to animation:
The CompositionTarget.Rendering event causes WPF to continuously animate. If you use this event, detach it at every opportunity.
When you use a Brush to set the Fill or Stroke of an element, it is better to set the Brush.Opacity value rather than the setting the element's Opacity property. Modifying an element's Opacity property can cause WPF to create a temporary surface.
You may be able to update a Transform rather than replacing it as the value of a RenderTransform property. This is particularly true in scenarios that involve animation. By updating an existing Transform, you avoid initiating an unnecessary layout calculation.
Here is what I have learned through trial and error:
Say, you have a couple of elements with a Effect such as the BlurEffect applied. It is way faster to apply the effect to the container of these elements rather than the elements themselves. Even though the effect is hardware accelerated, WPF doesn't seem to be good at handling a number of small items with effects. - If you don't want the same blur radius and cannot group them in a container with the effect applied, it is actually faster to render the element to a bitmap (in software) and then animate the bitmap around (if that is possible). Having effects (or opacity for that matter) on objects quickly kills performance when animating.
Setting the opacity on the brush rather than the element (as mentioned further above) makes a huge performance difference when animating objects.
Keep the number of visuals down. Animating a large number of particles is difficult, even with the above tips. In this case you may need to revert to WriteableBitmap instead.
I have also heard that it is faster to render many little objects by overriding OnRender in the container and then rendering them using the drawingContext rather than adding them to the visual tree directly. In practice this didn't make any difference in my scenario (when rendering around 300 ellipse geometries) but it might be helpful in some scenarios. The theory sounds solid.
Finally, I have found the animation classes built into WPF way too cumbersome and had much more fun and success using the underdog of animation libraries: Artefact Animator. Seriously, give it a try. (it is also available for Silverlight) It is what animating (in code) should have been like.
All is not rainbows and unicorns though. I still find it impossible to create truly fluid animations when running full screen in higher resolutions. More on that in my question How to know why an animation stutters? - I would appreciate any input on that.
cheers, good luck and if you have something cool to show, let me know :)
This question is fairly straightforward -- I am trying to debug a memory leak in a silverlight application using s.o.s. I was able to get some good info using !gcroot to determine what objects have open references to the one that should be getting cleared; but in these cases they tend to be core UI elements (like grid and storyboard), and I can't really differentiate them without the ability to see the values of their dependency properties (like name). Trying to look through the dependency properties with !dumpobj is a total wild goose chase for me, they are all static classes (the properties that is) that reference each other and I just end up going in circles. At no point was I ever able to find a single actual value for a dependency property anywhere.
I googled about this quite a bit, but was only able to find other people asking the question, or speculation not leading to an answer. http://blogs.msdn.com/tess/archive/2008/09/16/q-a-reader-emails-about-net-memory-leaks-and-random-questions.aspx is one such page without answer.
Looking at the source of DependencyObject.GetValue in Reflector makes me think that this is non-trivial to do in Windbg. As an alternative (and a hacky one, I admit), in your own classes you could bind a standard CLR property to the Name DP, so that you do have a value that you can read in the debugger.