mvvmfoundation Issue Tracker Rss Feed

Created Issue: unloading/dealloc usercontrol DataContext [8765]

zxed — Thu, 17 Jun 2010 18:21:12 GMT

It would probably be more helpful if i created a demo app and replicated the memory leak. I will try explaining my issue and if that doesnt work ill put together a demo app
1 Window
10 User controls

Window holds dynamic user controls container.... that is ..... <UserControl Content="{Binding Path = UserViewControl....
Window also has 10 buttons, each buttons swaps out the windows user control container with a control...

User controls are loaded into the window
Each user control has its ViewModel that it sets the UserControl.DataContext to. i.e.
<UserControl.DataContext>
<vm:xViewModel></vm:xViewModel>
</UserControl.DataContext>

So whats the problem?
well., I see that if i open up xUserControl which loads xViewModel, i see the program memory increase, then if i navigate to Y, i.e yUserControl which loads yViewModel i get another memory increase.. If i go back to a previously opened view model, it doesnt do increase memory again. most probably because of the autofac/ioc containers being used...

in a nutshell when i swap out usercontrols in the usercontrol container, it doesnt release the ViewModel that was set in the usercontrols datacontext....

I guess i could hook into the Unloaded method for usercontrols... but what/how do i dealloc the datacontext?

Does my question even make sense?

Commented Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

MattHeffron — Fri, 06 Nov 2009 18:31:55 GMT

The VerifyPropertyName debugging code fails if used on a static or protected properties.
This changes the test to work for the more general case. (It allows private properties but there isn't an *easy* way to exclude them.)

Matt Heffron

public void VerifyPropertyName(string propertyName)
{
// If you raise PropertyChanged and do not specify a property name,
// all properties on the object are considered to be changed by the binding system.
if (String.IsNullOrEmpty(propertyName))
return;

// Verify that the property name matches a real property on this object.
try
{
PropertyInfo propertyInfo = this.GetType().GetProperty(propertyName,
BindingFlags.Public | BindingFlags.NonPublic |
BindingFlags.Static | BindingFlags.Instance |
BindingFlags.FlattenHierarchy);
if (propertyInfo == null)
{
string msg = "Invalid property name: " + propertyName;

if (this.ThrowOnInvalidPropertyName)
throw new ArgumentException(msg);
else
Debug.Fail(msg);
}
}
catch (AmbiguousMatchException)
{
return; // Well...the name *IS* there...
}
}
Comments: ** Comment from web user: MattHeffron **

But the RaisePropertyChanged, at least in my case, does pass an instance of the class as the sender. (The class is not static, but the property is.)

Commented Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

JoshSmithOnWpf — Fri, 06 Nov 2009 16:21:20 GMT

On second thought, how would the binding system know which class the property belongs to? If you were to raise PropertyChanged where e.PropertyName="FooProperty" and sender=null, how would a binding know which class FooProperty is on? I've never tried this, and am not sure if it would even work.

Josh

Commented Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

JoshSmithOnWpf — Fri, 06 Nov 2009 16:19:01 GMT

I see what you mean, Matt. I am thinking of maybe adding a static version of RaisePropertyChanged. Alternatively, could you have those static collections be ObservableCollections (or ReadOnlyObservableCollections) to get the change notifications you need? Thanks!

Josh

Commented Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

MattHeffron — Wed, 04 Nov 2009 20:49:55 GMT

I have several ViewModel classes that have static properties exposing "almost constant" collections that I bind to. (The collection values are constant, but need to be sorted based on the CurrentCulture which can be changed on-the-fly.) I need to be able to RaisePropertyChanged() on those properties when the CurrentCulture changes so WPF gets the reordered collection.

I'm willing to concede non-public properties as a potential bug. I don't need them. (I sort-of went overboard with the GetProperty flags.)

Commented Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

JoshSmithOnWpf — Wed, 04 Nov 2009 06:08:16 GMT

Matt,

Thanks for your feedback.

I had considered adding support for non-public properties, but it presented oddities so I didn't do it. I built ObservableObject to make it easy to notify the WPF binding system of property changes. A Binding can only bind to public properties on an object, so it seemed like a bug to consider a protected/internal/private property as "valid" when raising PropertyChanged. Suppose I have an object with two properties: PublicProp and ProtectedProp (whose access modifiers are implied by the property names). If I accidentally pass "ProtectedProp" to RaisePropertyChanged() from the PublicProp setter, it would be considered valid. That might seem like a bug. Perhaps you can convince me otherwise...

Please explain the static property scenario. What use case do you have in mind?

Thanks,
Josh

Created Issue: ObservableObject.VerifyPropertyName excludes static or protected properties [6139]

MattHeffron — Wed, 04 Nov 2009 03:57:38 GMT

Commented Issue: Unregistering from Messenger [5808]

JoshSmithOnWpf — Thu, 15 Oct 2009 17:27:39 GMT

Hi,

I have been using your classes for a while now and I have a question regarding the Messenger class. I your WpfDemoApp, from the NumberChangeLogView constructor, you register like the following:
App.Messenger.Register(
App.MSG_LOG_APPENDED,
new Action(() => _scrollViewer.ScrollToBottom()));
If I debug step into Register method and look at the Action object, callback, in Watch list the value is said to be: {Method = {Void <.ctor>b__0()}}
My question is: why is it the constructor (ctor) displayed here? Why isn't it the simply method ScrollToBottom.
The reason of my question? I tried to add an unregister method to your Messenger to be called like the following:
App.Messenger.Unregister(
App.MSG_LOG_APPENDED,
new Action(() => _scrollViewer.ScrollToBottom()));
That call should retrieve the action registered and remove it from the map list. The problem is, since that call will be made elsewhere than in the constructor, I end up having a different action object which is not equal to the one passed in parameter on registration. So I cannot retrieve the action and unregister it.

To give an example, in my project I registered a save message from my constructor:
App.Messenger.Register(
App.MSG_SAVE,
new Action(() => this.Save()));
So in the messenger, the action had a value of (in debug window Watch List):
{Method = {Void <.ctor>b__0()}}
And I unregistered from my method OnDispose, and the action came out to be:
{Method = {Void <OnDispose>b__2()}}

I know you said it is unnecessary to unregister because of weakreferences, but I have a case where I would like to unregister manually so I was wondering what is your thought on it. How can it be implemented?
Comments: ** Comment from web user: JoshSmithOnWpf **

I used a lambda expression in my example because I had no need to unregister. A lambda expression, at the end of the day, is just a delegate (i.e. a strongly typed callback).

Commented Issue: Unregistering from Messenger [5808]

GIJoe — Thu, 15 Oct 2009 16:27:28 GMT

Little mistake:

Thanks for the answer. It worked. But is there a drawback doing it this way? I mean why did you use lambda expression?

Pascal

Commented Issue: Unregistering from Messenger [5808]

GIJoe — Thu, 15 Oct 2009 16:26:35 GMT

Hi Josh,

Thanks for the answer. It worked. But is there a drawback doing it this way? I mean did you use lambda expression?

Pascal

Commented Issue: Unregistering from Messenger [5808]

JoshSmithOnWpf — Thu, 15 Oct 2009 15:55:07 GMT

The method name is {Void <.ctor>b__0()}} because the Action object contains a lambda expression as its callback. That lambda expression is basically turned into a separate method by the compiler, and it is assigned a compiler-generated name. If you want to unregister a callback, don't use lambda expressions. Instead, when creating the Action object, pass in the name of a callback method that you created (so that it doesn't have a compiler-generated name).

HTH,
Josh

Created Issue: Unregistering from Messenger [5808]

GIJoe — Thu, 15 Oct 2009 14:24:49 GMT

Commented Issue: ViewModels not being thrown away [5734]

JoshSmithOnWpf — Wed, 14 Oct 2009 18:27:37 GMT

Hey i cant find a good place to post this, so ill try here first.
Im having a problem with my ViewModels never being GC'ed until the app is shutdown. This is a major issue! Can you pros lend some ideas as to exactly what could be the cause of them never being released? Im using a tabbed style app, where you can open as many Entity tabitems(viewmodels) as you want, and then close them when youre done. The examples Ive seen from disciples they always limit the number of open VMs at once...am I missing something, doing something wrong? Im using Joshs/Marlons Mediator to send out messages, with a static Mediator singleton in my base viewmodel...could that be a culprit?

Thanks!
Justin
Comments: ** Comment from web user: JoshSmithOnWpf **

It could be any number of things in the app. If you can create a simple demo application that consistently causes a memory leak due to one of the classes in MVVM Foundation, please send it to me and I will investigate. Otherwise, it's impossible for me to even start providing suggestions on how to plug the memory leak in your app.

Josh

Created Issue: ViewModels not being thrown away [5734]

ftballguy45 — Fri, 09 Oct 2009 19:10:44 GMT

Commented Issue: PropertyObserver: added handlers that pass property name & CollectionObserver

MattHeffron — Mon, 24 Aug 2009 17:34:32 GMT

Since the PropertyChangedEventArgs already has the property name, and it is frequently (at least for me!) the case that I'm just passing the change notification from a model property to a ViewModel property of the same name. I added a second PropertyObserver.Register method that takes a two parameter action (the second parameter is string). When invoked the property name is passed as the value of that parameter.

Also, I added a CollectionObserver class that does WeakEvent connection to INotifyCollectionChanged. It catches changes to the collection itself (unlike the Charles Petzold msdn article, which deals with changes to the items IN the collection.) The registrations are specific by the enum NotifyCollectionChangedAction.

Code (and simple unit tests) attached.
Comments: ** Comment from web user: MattHeffron **

The justification for the two parameter handler in the PropertyObserver.RegisterHandler (not .Register, a typo in the original Description above) is where the View Model has a property which has the same name as a Model property but is just a controlled formattingt of the value.
E.g.,
public string RealTemperature { get { return GetFormattedOutputTemperature(TheRunConditions.RealTemperature); } }
The handler registered on the RealTemperature property of the model (TheRunConditions) needs only to raise the PropertyChanged event for the ViewModel in order for WPF to update the display. Since there are several such property-pairs in my Model-ViewModel, I have a simple handler that is registered for them all:
RunConditionsObserver = new PropertyObserver<RunConditions>(TheRunConditions)
.RegisterHandler(rc => rc.RealTemperature, PassThroughRaisePropertyChanged)
.RegisterHandler( ... etc

void PassThroughRaisePropertyChanged(object ignore, string propertyName)
{ RaisePropertyChanged(propertyName); }

In this way the registered handlers don't need to have the property names "hard coded".

Reopened Issue: PropertyObserver: added handlers that pass property name & CollectionObserver

JoshSmithOnWpf — Sun, 23 Aug 2009 19:08:29 GMT

After revisiting this item, I realized that you are proposing two new, unrelated additions. I should have been more thorough before closing this item! I very much like the CollectionObserver class, and can think of several situations in which I would have used it. I will reconsider this proposal. Great work!

Closed Issue: PropertyObserver: added handlers that pass property name & CollectionObserver

JoshSmithOnWpf — Sun, 23 Aug 2009 18:56:55 GMT

feature declined

Commented Issue: PropertyObserver: added handlers that pass property name & CollectionObserver

JoshSmithOnWpf — Sun, 23 Aug 2009 18:56:42 GMT

Thanks for this suggestion, Matt. At this time I'm not going to add it to the library, because I have never found myself wanting this particular feature, and it introduces a new type to the library (CollectionObserver). I might be overly conservative, but my overarching goal with MVVM Foundation is to keep it as minimal as possible. Perhaps one day I will come around, and add it. Thanks again!

Closed Issue: Messenger.NotifyColleagues invokes registered delegates in reverse order.

JoshSmithOnWpf — Sun, 23 Aug 2009 18:45:42 GMT

I discovered that the registered delegates for a given message are invoked in the reverse order of registration. In my application, I needed to ensure some specific delegates were invoked before all the others. I added following 1 line (and comment) to MessageToActionsMap.GetActions(...) right before the final "return actions;"
// Because it *may* be important to preserve the order of the original weakActions List
// and weakActions was traversed in reverse order, reverse the final list.
actions.Reverse();
Comments: Resolved with changeset 32506.

Closed Issue: Test fails in Release build

JoshSmithOnWpf — Sun, 23 Aug 2009 18:45:42 GMT

A minor defect, but one that irks the test-infected :
The test method ObservableObjectTest.InvalidPropertyNameIsReported fails in the Release build : indeed it is testing a feature that is documented as belonging only in Debug builds !
That method should thus probably be surrounded with #if(DEBUG)/#endif or tagged with some equivalent attribute.

I'll finish by hijacking this issue ticket to say thanks a lot for sharing all the good stuff on WPF for all this time ! :)
Comments: Resolved with changeset 32506.