|
I was just going to say that, scroll bars are a great candidate for a typed style rather than x:key="" type. Nice and consistent.
|
|
|
|
|
Thanks Mark,
I achieved what I was looking for.
|
|
|
|
|
Hi,
What's a good method to bind Commands to Events? In my WPF app, there are events that I'd like to capture and process by my ViewModel but I'm not sure how. Things like losing focus, mouseover, mousemove, etc. Since I'm trying to adhere to the MVVM pattern, I'm wondering if there's a XAML solution for that.
Thanks!
|
|
|
|
|
These events are, strictly speaking, view only events, so why would you want them to be handled in the VM? There's no rule that says you can't have code behind the view, so if you need to do things, you can do it there. What are you trying to do that goes beyond the V/VM separation?
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi Pete,
Those events were just examples. It can be any type of event that I might need to handle.
In our application we can change XAML files dynamically, so we're trying to avoid solutions that involve code-behind files.
Thanks!
|
|
|
|
|
|
Attached behaviours are a good way to go - and one I'm particularly fond of (see this[^] blog post for an example).
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I don't know your actual requirement but ICommand can be helpful in such situations.
It makes your view cleaner.
May I get the exact scenario for the problem?
Niladri Biswas
modified on Thursday, June 4, 2009 10:32 AM
|
|
|
|
|
I suspect you meant to raise this against the OP, not me. He won't be notified of posts against my account, so could you reply to him instead.
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I don't know your actual requirement but ICommand can be helpful in such situations.
It makes your view cleaner.
May I get the exact scenario for the problem?
Niladri Biswas
|
|
|
|
|
Look I marked the property Data:
[DataMember]
public List<object> Data
{
get;
set;
}
and I still have this exception dislayed:
"Method get_Data is not supported on this proxy, this can happen if the method is not marked with OperationContractAttribute or if the interface type is not marked with ServiceContractAttribute".
thank you !
|
|
|
|
|
And is your contract interface marked with ServiceContract? Have you placed your DataMember on the implementation and not the interface?
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Here is approximately my code:
[ServiceContract]
public interface X
{
[DataMember]
List<y> Data {get;} //Y is a new type
}
[Data Contract]
public class Y
{
[DataMember]
public List<object> Data
{
get;
set;
}
}
Do I do any mistake?
|
|
|
|
|
The actual service contract is defined as an interface like this:
[ServiceContract]
public interface IMyInterface
{
[OperationContract]
List<int> DoSomething(MyData item);
} This contract will be implemented by a concrete class, and DoSomething will be visible to systems that consume the service. The DataContract is defined as a concrete class like this:
[DataContract]
public class MyData
{
[DataMember]
public int DataValue1 { get; set; }
[DataMember]
public string Identifier { get; set; }
} Then we define the class that implements the service contract like this:
public class ImplementInterface : IMyInterface
{
public List<int> DoSomething(MyData item)
{
return item.DataValue1;
}
}
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Excuse me I miss something:
[ServiceContract]
public interface X
{
[DataMember]
List<Y> Data {get;}
}
[Data Contract]
public class Y
{
[DataMember]
public List<object> Data
{
get;
set;
}
}
Having read your code I does not see why mine is incorrect
|
|
|
|
|
Is class Y supposed to inherit interface X?
If so, you haven't shown that, and why do you have
List<Y> in interface X and List<object> in class Y?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
The class Y doesn't inherit from the interface X, May be the confusion come because I gived the same identifier "data" for two different things!
I create the class Y just to define a new type (structured type) wich is not just composed from List<object> but other DataMembers such as string, int and a new other type Z, wich I create exactly in the same way as Y
and in my interface X, I have a DataMember (a property) wich type is List<y>.
Perhaps I not very Bright to express what I mean, therefore I detail the code of class Y and class Z down:
[DataContract]
public class Y
{
[DataMember]
public int id {get; set;}
[DataMember]
public string Str {get; set;}
[DataMember]
public Z NewType {get; set;}
[DataMember]
Public List<object> Data {get; set;}
}
[DataContract]
public class Z
{
[DataMember]
public int idz {get; set;}
[DataMember]
public string Strz {get; set;}
}
Thank you in advance Mark Salsbery !
|
|
|
|
|
You've create a ServiceContract here, but you are using DataMembers. DataMembers belong to DataContracts - not ServiceContracts. In a ServiceContract, you use OperationContract to mark methods that will be consumed. Take another look at the code I gave you, and pay particular attention to which attribute is defined against which type.
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
But here it is not a method but a property in my ServiceContract, if I mark it with [operationContract] I have this error:
<big>Attribute 'OperationContract' is not valid on this declaration type. It is only valid on 'method' declarations.</big>
Is it impossible to declare a property in a ServiceContract ?
|
|
|
|
|
It's not impossible - you just have to do it slightly differently. What you do, is declare OperationContract on your get and set, so you get:
public int MyProperty
{
[OperationContract]get;
[OperationContract]set;
}
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
thank you pete O'Hanlon , It is what I was looking for and thank you again
|
|
|
|
|
You're welcome.
"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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi All,
I've just noticed something in the Juval Lowy book I'm reading at the mo. He hasn't actually mentioned this in the text but I've noticed that all his DataContract are structs not classes.
Kinda makes sense really, are you WCF'ers out there tending to do the same with your DCs?
Cheers,
|
|
|
|
|
Nope, and here are my reasons:
- If your contract isn't small, a struct doesn't make much sense. If we assume you have non-trivial data, then the stack usage more than outweighs the prevention of heap allocation that structs bring to the table.
- You cannot use default constructors or field initializers with structs, which we use a fair bit.
- Structs tend to make sense when they are used in lots of places. Assuming that they don't form a large part of your architecture, then you aren't going to see much benefit from 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.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi Pete,
I was just thinking about in terms of the internal server farm project I'm working on. I've designed a set of base data classes for our database team to use in relation to reading data from the DB and then shoving it down the pipe to a WCF service. They are small data classes.
Might need to do some testing around this to help weigh up the pros and cons.
Cheers,
|
|
|
|