How to bind two properties in a class wpf
I would like to bind two properties in the viewmodel.
public class MainViewModel : INotifyPropertyChanged
public string Format
get return format;
set
if (format != value)
format = value;
OnPropertyChanged("Format");
public string FilterString
get return filter;
set filter = SomeFunction(value);
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(string propName)
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
So when the Format property changes It invokes FilterString set method.
What is the correct way of doing this.
c# wpf mvvm binding viewmodel
|
show 1 more comment
I would like to bind two properties in the viewmodel.
public class MainViewModel : INotifyPropertyChanged
public string Format
get return format;
set
if (format != value)
format = value;
OnPropertyChanged("Format");
public string FilterString
get return filter;
set filter = SomeFunction(value);
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(string propName)
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
So when the Format property changes It invokes FilterString set method.
What is the correct way of doing this.
c# wpf mvvm binding viewmodel
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
I don't understand the problem - from the setter ofFormatyou can callFilterString = whatyouwant. Just don't forgetOnPropertyChanged("FilterString")then.
– Nicolas
Nov 13 '18 at 13:19
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32
|
show 1 more comment
I would like to bind two properties in the viewmodel.
public class MainViewModel : INotifyPropertyChanged
public string Format
get return format;
set
if (format != value)
format = value;
OnPropertyChanged("Format");
public string FilterString
get return filter;
set filter = SomeFunction(value);
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(string propName)
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
So when the Format property changes It invokes FilterString set method.
What is the correct way of doing this.
c# wpf mvvm binding viewmodel
I would like to bind two properties in the viewmodel.
public class MainViewModel : INotifyPropertyChanged
public string Format
get return format;
set
if (format != value)
format = value;
OnPropertyChanged("Format");
public string FilterString
get return filter;
set filter = SomeFunction(value);
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(string propName)
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propName));
So when the Format property changes It invokes FilterString set method.
What is the correct way of doing this.
c# wpf mvvm binding viewmodel
c# wpf mvvm binding viewmodel
asked Nov 13 '18 at 13:14
Yinon DotanYinon Dotan
529
529
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
I don't understand the problem - from the setter ofFormatyou can callFilterString = whatyouwant. Just don't forgetOnPropertyChanged("FilterString")then.
– Nicolas
Nov 13 '18 at 13:19
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32
|
show 1 more comment
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
I don't understand the problem - from the setter ofFormatyou can callFilterString = whatyouwant. Just don't forgetOnPropertyChanged("FilterString")then.
– Nicolas
Nov 13 '18 at 13:19
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
I don't understand the problem - from the setter of
Format you can call FilterString = whatyouwant. Just don't forget OnPropertyChanged("FilterString") then.– Nicolas
Nov 13 '18 at 13:19
I don't understand the problem - from the setter of
Format you can call FilterString = whatyouwant. Just don't forget OnPropertyChanged("FilterString") then.– Nicolas
Nov 13 '18 at 13:19
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32
|
show 1 more comment
1 Answer
1
active
oldest
votes
You can use a WPF multibinding to bind a control to two fields, but in this case I think it makes more sense that the ViewModel would change FilterString when the Format is changed.
You'd use a multibinding when a control's value depends on two things because that's a GUI feature. In your case the ViewModel properties are logically linked, so it makes more sense for the code to be in the ViewModel.
To help you decide which pattern to use, ask yourself whether you'd want the same behaviour if you reused the ViewModel elsewhere.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281807%2fhow-to-bind-two-properties-in-a-class-wpf%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can use a WPF multibinding to bind a control to two fields, but in this case I think it makes more sense that the ViewModel would change FilterString when the Format is changed.
You'd use a multibinding when a control's value depends on two things because that's a GUI feature. In your case the ViewModel properties are logically linked, so it makes more sense for the code to be in the ViewModel.
To help you decide which pattern to use, ask yourself whether you'd want the same behaviour if you reused the ViewModel elsewhere.
add a comment |
You can use a WPF multibinding to bind a control to two fields, but in this case I think it makes more sense that the ViewModel would change FilterString when the Format is changed.
You'd use a multibinding when a control's value depends on two things because that's a GUI feature. In your case the ViewModel properties are logically linked, so it makes more sense for the code to be in the ViewModel.
To help you decide which pattern to use, ask yourself whether you'd want the same behaviour if you reused the ViewModel elsewhere.
add a comment |
You can use a WPF multibinding to bind a control to two fields, but in this case I think it makes more sense that the ViewModel would change FilterString when the Format is changed.
You'd use a multibinding when a control's value depends on two things because that's a GUI feature. In your case the ViewModel properties are logically linked, so it makes more sense for the code to be in the ViewModel.
To help you decide which pattern to use, ask yourself whether you'd want the same behaviour if you reused the ViewModel elsewhere.
You can use a WPF multibinding to bind a control to two fields, but in this case I think it makes more sense that the ViewModel would change FilterString when the Format is changed.
You'd use a multibinding when a control's value depends on two things because that's a GUI feature. In your case the ViewModel properties are logically linked, so it makes more sense for the code to be in the ViewModel.
To help you decide which pattern to use, ask yourself whether you'd want the same behaviour if you reused the ViewModel elsewhere.
answered Nov 13 '18 at 13:36
Robin BennettRobin Bennett
1,497112
1,497112
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281807%2fhow-to-bind-two-properties-in-a-class-wpf%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Set the FilterString property in the setter of the Format property?
– mm8
Nov 13 '18 at 13:19
I don't understand the problem - from the setter of
Formatyou can callFilterString = whatyouwant. Just don't forgetOnPropertyChanged("FilterString")then.– Nicolas
Nov 13 '18 at 13:19
Ok I understand but Is that the correct way to bind properties in a class? or should events be used or other design pattern.
– Yinon Dotan
Nov 13 '18 at 13:23
It seems like FilterString should be a read-only property that returns the value of SomeFunction. Does SomeFunction use the value of the Format property or how are the two properties related?
– mm8
Nov 13 '18 at 13:23
What kind of logic the properties have to do (have to implement in their setter) is independent of the property binding. I may be wrong, but maybe your question means if it is a good approach to do more stuff in the property setters, that may delay the processing (= the UI). You may do the actions async then...
– Nicolas
Nov 13 '18 at 13:32