WPF Discussion Boards

8-Feb-10 21:52

If you take a look at my article (page 18) in this e-book[^], you should get a little bit of an idea why WPF is so powerful.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Problem w/ ClickOnce deployment and EventLogs

WPF

Syed Shahid Hussain8-Feb-10 11:08

Syed Shahid Hussain

8-Feb-10 11:08

hi all

What is the Performance, worth and scope of WPC. Is it known a better thing from microsoft or not? Can anyone answer the worth of WPF?

Thanks

Syed Shahid Hussain

Re: WPF

Not Active8-Feb-10 11:17

Not Active

8-Feb-10 11:17

http://www.codeproject.com/Messages/3122371/How-to-get-an-answer-to-your-question.aspx[^]

Take a look at #3. WPF as a subject in the WPF forum is useless.

I know the language. I've read a book. - _Madmatt

Re: WPF

V.8-Feb-10 21:25

8-Feb-10 21:25

try this What is WPF?[^]

vsaratkar8-Feb-10 9:46

vsaratkar

8-Feb-10 9:46

Hi,

I have a wpf application and for DispatcherUnhandledException exception, I want to write an entry in system log.

if (!EventLog.SourceExists("ApplicationName"))
			    EventLog.CreateEventSource("ApplicationName", "Error Log");

EventLog.WriteEntry("ApplicationName", e.Exception.Message + "\n" + "Stack Trace:" + "\n" + e.Exception.StackTrace,EventLogEntryType.Error);

Above code is working fine on development machine on deployment, since I have administrative rights.

But on the client machine, user not having administrative rights can not run application on clickOnce deployment.
This is because EventLog.CreateEventSource method requires administrative rights.

ClickOnce deployment is per user deployment and very handy.

So, I was wondering if there is any technique to write event logs.

I am writing errorlog to a text file for now.

Thanks,
Vsaratkar

Dragging outlook attached documents into a WPF app

RugbyLeague8-Feb-10 3:59

RugbyLeague

8-Feb-10 3:59

Can anybody point me in the right direction how to do this please.

I have found a few samples showing how to do it in WinForms but they all say it doesn't work in WPF.

The files I will be dragging into the WPF app will all be text files so it doesn't need anything fancy.

Re: Dragging outlook attached documents into a WPF app

Pete O'Hanlon8-Feb-10 4:24

8-Feb-10 4:24

The functionality in this[^] article works in WPF.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Re: Dragging outlook attached documents into a WPF app

RugbyLeague8-Feb-10 5:34

RugbyLeague

8-Feb-10 5:34

Thanks, that works. I had seen it during an earlier search but it only does single files - but its better than no files so it will do for now Smile | :)

MVVM standardization [modified]

Michael Sync7-Feb-10 5:46

Michael Sync

7-Feb-10 5:46

Hello,

Someone in Silverlight posted[^] that MVVM currently lacks standardization so that everyone has own favor..

That's why Me and a few guys from WPF Disciples are actively discussing about MVVM that everyone agreed. I totally understand that we have implemented the pattern in different ways and we mixed the several patterns or create our own pattern based on our project's need or to make the developers' life easier.. But forget about those difficulties or the special need of your project. Let's discuss about the standard rules of MVVM pattern that everyone agreed. I posted some of my thoughts here[^] as well.

Why MVVM?

- Testabiltiy ( ViewModel is easier to unit test than code-behind or event driven code)
- Clear seperation between UX designer and developer
- Increases the “Blendability” of your view
- Model never needs to be changed to support changes to the view
- ViewModel rarely needs to be changed to support changes to the view
- No duplicated code to update views

Do and Don’t in View

- shouldn’t contain any logic that you want to test : As Glenn said that MVVM is not code counting exercise, we can write code in code-behind. But you should never write any logic that you want to test. For example: If user select a country then you want to display the list of states or city in your view. This is the business requirement so you should have unit test to test this logic. So, you shouldn’t write it in code-behind.
- can be a control or Data Template
- Keep the view as simple as possible. : We can still use Data Trigger or Value Converter or Visual State or Blend Behivor in XAML with care.
- use attached property if something is not bindable :

Do and Don’t in ViewModel

- Connector between View and Model
- Keep View State, Value Conversion (You can create the data structure that you want to display in ViewModel instead of using ValueConverter. For example: You need to show the Name instead of First Name and Last name. Your Model can have First Name and Last Name but You can create Name property in ViewModel. )
- No strong or weak (via Interface) reference of View
- Make VM as testable as possible (e.g. no call to Singleton class)
- No Control related Stuff in VM ( Because if you are changing the view then you will have to change VM as well. )

Model

- can be Data Model, DTO, POCO, auto-generated proxy of domain class and UI Model based on how you want to have the separation between Domain Service and Presentation Layer
- No reference to ViewModel

Do you have any suggestion or comment for that?

We have one disagreement in our group. Some said that it's okay to have the interface of View in ViewModel. But some said that if View Model has the interface of View then it will be MVP pattern.

One of our MVVM experts say about MVVM Vs MVP

**View => ViewModel**

- MVVM the view is directly bound to the ViewModel and talks to the VM through databinding
- In MVP, the view is bound to a model hanging off the SupervisingController or not bound at all (passive view).

**ViewModel => View**

MVVM

1. INPC / Property binding
2. Events
3. Messages (Event Aggregator/Messenger/RX framework)
4. Through an intermediary such as a service
5. Through an interface
6. Through delegates (View passes delegates to the VM which it can use to call it back. For example VM might expose a SetActions method which the View calls passing it delegates.

MVP

1. With Passive View the properties are not using databinding, instead the view property getters and setters are used to directly set the control value.
2. Events
3. Messages (Event Aggregator/Messenger/RX framework)
4. Through an intermediary such as a service
5. Through an interface
6. Through delegates (View passes delegates to the VM which it can use to call it back. For example VM might expose a SetActions method which the View calls passing it delegates.

MVP Vs MVVM

All are the same except the following.

1. View talks to ViewModel via binding. In MVP, View directly calls the Presenter.
2. ViewModel has INPC / Property binding while Presenter doesn't have. Presenter set the value to the property of control directly.

The rest are the same.

What do you think about that idea?

Do you think that it's okay for ViewModel have the interface of View?

If you like to add more then you are welcome to add... Smile | :)

The whole idea about this post is to get the same understanding of MVVM pattern in Community. Feel free to let me know if you have any comment or doubt. Thanks.

modified on Sunday, February 7, 2010 10:10 PM

Re: MVVM standardization

Wes Aday8-Feb-10 12:35

Wes Aday

8-Feb-10 12:35

Michael Sync wrote:
Do you think that it's okay for ViewModel have the interface of View

There is one simple reason why I think that it's okay for the VM to have a reference to the interface for the view.... I do not know of any reason why it is forbidden.... it's not like you are directly referencing a View.... it's an interface that the view happens to implement. Many views can implement the same interface so you are not tying the VM to a particular view.

Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns

Help humanity, join the CodeProject grid computing team here

DataTemplate with List binding

pbalaga6-Feb-10 9:20

pbalaga

6-Feb-10 9:20

Hi, I managed to bring to work simple data template in a ListView control:

<DataTemplate>
    <TextBox Text="{Binding Path=boo}" />
</DataTemplate>

Class of the items added to the ListView contains property 'boo' of type string.
But how to do similar binding for a custom complex type. Let's say instead of string boo,
I have List<int> integers;. What I'm trying to achieve is to make the textbox display
the numbers in the list separated with commas (e.g. 3,5,15,2).
In other words, is it possible to do something like

<TextBox Text="{Binding Path=integers}" />

by providing how the target should be formatted?
The main issue is that it should be a two-way binding (with ability to convert "1,5,4" back to List<int>).

What direction to go? I assume I could implement a string property, i.e. 'NumbersString' returning
joined contents of the list in form of a single string. Or maybe it has something to do with converters?

I only hope my explanation is clear enough.

Thanks in advance,
Paul

Pete O'Hanlon6-Feb-10 9:58

6-Feb-10 9:58

One way to do this would be to use a ViewModel approach, and bind to a string property that aggregates this data. Consider the following sample:

public class MyClass
{
  private List<int> _myList = new List<int>();
  public string AggregateList
  {
    get
    {
      if (_myList != null && _myList.Count > 0)
      {
        StringBuilder myString = new StringBuilder();
        foreach (int value in _myList)
        {
          sb.AppendFormat("{0},", value);
        }
        return sb.ToString().Substring(0, sb.ToString().Length - 2);
      }
      return string.Empty;
    }
    set
    {
      string[] values = value.Split(",");
      _myList.Clear();
      foreach (string item in values)
      {
        int output;
        if (int.TryParse(item, out output))
        {
          _myList.Add(output);
        }
      }
    }
  }
}

You could do something like this using converters, but this is a simple method - and you just need to bind to this property. I've just knocked this up in the HTML editor here, so there may be a mistake or two, so I apologise in advance for them.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

pbalaga6-Feb-10 21:35

pbalaga

6-Feb-10 21:35

Thank you for your time!

This should be enough in some cases, including my current issue, but it seems somewhat less flexible.
Let me be a bit curious, so what if an user wants to write his own style(?) and have the data separated
with semicolons, not commas?
May seem overcomplicated, but I'm asking, because it may happen that the end-user will be unable to
change the data input. So the List<int> will be always a List<int> without a chance to wrap it as above.

Thanks once again! Anyway I've just found a site about converter binding in xaml and I think it can be
highly educational.

Pete O'Hanlon6-Feb-10 22:01

6-Feb-10 22:01

You could use a converter if you wanted - if the user wants to write his own style though, you are faced with having to change the code anyway. The sample I posted was aimed at satisfying your problem - it's designed around POCO (Plain Old CLR Objects) which means that it's easy to test.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Abhinav S6-Feb-10 10:06

Abhinav S

6-Feb-10 10:06

You could put the textbox in a stackpanel and then set the stackpanel's orientation to horizontal.

Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...