|
Here are two examples can be run, using VS2008 and. Net FrameWork3.0。
https://skydrive.live.com/redir.aspx?cid=8f125a6da8d15aee&resid=8F125A6DA8D15AEE!103
Delay example, the longer the draw, between the mouse and lines will be a very significant delay (after the mouse to stop, delay disappeared), and CPU utilization much, mainly because of the mouse each take a sampling point, we need to re-draw the lines；Non-delayed example you will find that handwriting is very smooth, although take up memory, but not as good as the first clear, the key is not that obvious delay.
My aim is to achieve multi-pen, refers to more than one person can use the stylus on the touch pad or finger free writing, which requires hardware support. Currently there is no hardware problem, the problem is a multi-pen when the delay is not significant (due to hardware limitations, there will be some delay in itself).
Examples of the use of delayed implementation, to achieve multi-pen, but the process caused the delay with the hardware itself, and do not make people suffer; example if the non-delay multiple ways to achieve freedom of writing, then, is an ideal, but I can not find how to DynamicRenderer the RootVisual simultaneously display different handwriting method.
What should I do here? how achieve multi-pen? Are there other ways? Please help me!
|
|
|
|
|
Hi,
How to get WM_Gesture/touch messages form windows 7 in WPF 4.0 touch aware application?
Currently I am only able to get Gesture notify message but not actual WM gesture message. but same we can get in win Forms.
|
|
|
|
|
Hi,
I work with WPF, and I have got a problem with binding a listbox.
The question is as follows.
I have a left list box of ten list box items. On the right hand I have a border where I can exchange between 10 User Controls.
So, I have a 10 listbox items for ten usercontrols. The problem is how to bind these 10 listitems and make them as a menu, so when I click on one of them I get the right User Control on the right side..
If ther is any solution, send please!
|
|
|
|
|
Thanks for your contribution and your funny comment in the bottom!
I have done exactly what you have there up! But the problem is in the collection. Because I have different VM for different Views, I couldn't create an instance of a collection.
Even if I have done an Array list, it would be difficult to determine/create and index that would return the right UserControl!
|
|
|
|
|
I have VS2010. Of the dozen plus examples and papers on WPF I have tried I find all are out of date. Some only need to be tweaked a little. Some are useless. It seems like WPF has really been a work in progress. It is not the author’s fault that Microsoft keeps changing things so much. Not even Microsoft's since they are trying to improve things and have lots of competitive pressures. It is just plain frustrating.
Sometimes the author provides info on the VS and .NET versions but not always. It is really helpful when they do.
Is there a way that after we get an example working in new version we could posted the updated source code with the article
|
|
|
|
|
Well, you could try the book in the post below. You can download the code for the examples in C#/WPF4 for VS2010 - everything is up-to-date. Just a suggestion.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
I have that book. I also have Pro WPF in VB 2010. I find both useful. Surprisingly I find little duplication between the two books. I guess that shows how really monstrous WPF is.
|
|
|
|
|
I don't think it has changed that much. Its just that they've filled in a lot of the holes over time. You aren't really going to find a good, basic example of WPF MVVM because people usually post the full blown sample apps and you get all confused. Plus, theres about 10 different MVVM frameworks out there, so the way you do things in one might be completely different or missing from another.
Those books are good for simple, isolated examples, but they aren't very good for full blown app examples.
|
|
|
|
|
I do not see any difference between WPF and VMMV. I know technically there is but from a practical matter I open Visual Studio, select the language, and WPF project. That is WPF; that is the default VMMV. To me they are the same. That has been a moving target.
Case in point, DataGrid was not in VS2008 but is in VS2010. There were several versions of DataGrid before that and in an SDK. I find comments that even different revs of SDK had slight changes in DataGrid. Now we have VS2010 and it is even different yet. A moving target. All examples of DataGrid not done in VS2010 are useless. There are lots more examples.
I really agree with you comment about isolated examples not being very useful. It seems every time I try to combined things it blows up in WPF. It did not do that in Windows Application in either C++ or VB. I started with VS version 4 VB. Did C++ for many years. When .Net came along I when back to VB. It was just as structured as C++ by then. I got tired of all the extra punctuation and lines and brackets. The examples worked well then. They seemed easy compared to WPF.
|
|
|
|
|
Not at all. Winforms is pretty much managed MFC. You do things in the same exact way. You subscribe to events, intertwine business and UI logic, make things public as workarounds, global variables, etc. You *can* write WPF like that just fine. That is not MVVM. MVVM introduces architectural design patterns. It seperates UI from business logic pretty much completely. Also, you are doing everything via data-binding. If you are doing full blown proper MVVM, you are also delving into lots of the more advanced concepts like Dependency Injection, Services, Service Locator, etc. With Visual Studio 2010 and .NET 4.0, you can't do MVVM "out of the box" because the infrastructure support is not there. You need to add a 3rd party MVVM library or write your own.
-- modified 29-Sep-11 15:56pm.
|
|
|
|
|
I read some articles writen by Microsoft people and I think they would dissagree with you. But, they think VS is the answer to all things.
|
|
|
|
|
How so? What exactly are you disagreeing with? WPF is not MVVM. MVVM is not WPF. Nor is MVVM supported out of the box with no additional libraries or code. Microsoft doesn't claim to support MVVM with Visual Studio 2010. They just recommend you write WPF & Silverlight code in that style. Where is RelayCommand<T>? Where is your ServiceLocator or DI container? Where is Messenger? Those are not part of .NET at this time. Why do you think there are 10+ MVVM frameworks out there? Cinch by Sasha Barber is a popular one, MVVMLight, etc. Heck... even Microsoft itself has a library called Prism, although thats not purely an MVVM library, thats more on the MEF side of things.
You will find REALLY quickly, that if you are doing MVVM, you need a lot of support code.
For a simple example:
How do you close a dialog from the ViewModel? Normally, you just set DialogResult = true right? Too bad DialogResult is not accessible from the ViewModel  . Oh wait, guess what? Its not a bindable property either! So you can't bind it to something in your ViewModel. Guess you need some additional (3rd party) code to do that . If you google that, you'll find that what everybody is doing is using attached properties in a framework.
Another example where VS2010 does not support MVVM out of the box:
How does ViewModel1 communicate with ViewModel2? They aren't supposed to know about each other. Hmm... guess you need some sort of Messenger implementation for that. Too bad .NET 4.0 doesn't have one .
Yet another item:
How do you forward control events to the ViewModel? Thats not supported out of the box either... Darn... guess I need some additional generic code to do that .
|
|
|
|
|
I reread the article:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
I understand your "technical" view but my statements about a "practical mater" still stand.
Maybe my opinion comes from the type of programs I write. I do the glue. I start with two or more pieces of equipment and/or software that need to work together and do something the customer wants. They were not intended to work that way. I glue them together. I often name my programs DuckTape. Often it is just as much a UI as it is communications but always I am quickly in and out of a project.
I wonder how many people use a VMMV?? I doubt it is a majority.
|
|
|
|
|
Lol... pretty much everybody who writes WPF uses MVVM. Why do you keep calling it VMMV? WPF and MVVM go hand in hand. As I said, its not required, but its highly recommended by Microsoft.
If you are just hacking together quick apps, then yeah, MVVM is overkill. WPF is kind of overkill too. You could probably whip out a quick "DuckTape" app quicker with Winforms.
-- modified 29-Sep-11 18:30pm.
|
|
|
|
|
Winforms are quicker but I got board wanted to try something new. Also, you always need to keep learning.
VMMV. MVVM. Dyslexia I guess,
|
|
|
|
|
I see you've pointed to Josh Smiths excellent article on MVVM. FYI - Josh does not work for Microsoft. MVVM and WPF go hand in hand - in a large part, WPF was designed to be able to support MVVM. The problem is that people have it in for MVVM because they think that
a) you HAVE to use it for WPF; you don't, but it certainly makes it easier if you do
b) MVVM is complicated; it's no more complicated than other patterns
c) MVVM is all you'll need; it's not - MVVM is supported by a whole slew of other things such as IoC, DI, Service Location, Mediator/Messenger - all of which are well documented in their own right. More importantly, if you use another pattern such as MVC, you still end up having to use a lot of these techniques.
If you're knocking up a quick one off application for yourself, then MVVM is overkill. If you are intending to produce a professional application that has the model and UI interaction logic in a form that can be tested using good programming practice, then MVVM is perfect for you.
|
|
|
|
|
What I write works, customers are happy with it, they pay me a lot of money for it. What is not professional about that?
|
|
|
|
|
So you don't unit test your code?
|
|
|
|
|
There are lots of people and companies that slap stuff together and make it work. He already admitted thats what he does. There is certainly a market for it. Lots of people in mgmt or not technical positions believe that it is better to slap something together in a week that "works" vs. writing a well engineered solution that would take a month or two. I am seeing this more and more in the companies I work for  .
You certainly don't get rewarded or appreciated when you take 2x as long as the other guy, but your code is much better underneath. The other guy that cranked out a hack will be the hero. Sad, but true.
|
|
|
|
|
How would I know if it worked if I did not test it????
There is a an axiom about debugging code. "The only program in which you will no longer find bugs is that which is obsolete and no longer used."
|
|
|
|
|
So how are you automating your interaction logic tests to ensure it works? Are you unit testing your code behind with a standard test tool?
|
|
|
|
|
There are lots of ways to test things. Automated testers and dedicated testing tools are not always necessary. Methods depend on the complexity of the project. Ultimately it comes down to the user and that is the final test. Even if the code preforms perfectly and does everything ask for, if the user cannot understand how to make it work it has failed. Being facetious, I find my grade school children and friends work best for this testing.
|
|
|
|
|
Hmmmm. Okayyyyyy. I guess we have different standards by which we determine things as being "professional". If it works for you, then fine - feel free to ignore MVVM because your way of working is completely the opposite to the way that MVVM has been designed to support.
|
|
|
|
|
What if somebody has to go in and make changes? If your code is not maintainable, that is not a good thing.
|
|
|
|
|
Why do you think quality and maintainability have to do with speed? Some of the best pieces of code I have seen are short, concise, simple, and easy to understand. Also, without a lot of extras there is less room for bugs.
There are 2 ways to deal with bugs. The first is to add a lot of code to handle them. The second is to look for the fundamental cause and figure out how to shorten the existing code. When you add more code it is more room for bugs. I find those that take a lot of time have much longer programs and usually more hidden bugs. The second method takes more thought. It can be hard to suppress knee jerk reactions. Surprisingly the second method in total takes less time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
