|
|
|
Rank: Member
Groups: Registered
Joined: 9/14/2012
Posts: 4
|
It seems that on WpfTextBoxAdapter and possibly other classes a Dispose method has been implemented and also a finalizer. It's a little strange that the classes themselves don't seem to implement IDisposable but apart from that it doesn't seem that the Dispose methods are calling SuppressFinallze. My concern is that this may be resulting in some behaviour we are witnessing where a large tree of objects are spending a long time on the finalizer queue as a result.
Was this intentional?
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Hi, I think our use of the name "Dispose" for that method is the confusion. Dispose (not how we've used it, but generally) and IDisposable are for cleaning up unmanaged resources - but we don't actually have any unmanaged resources. When we designed the WPF version of RapidSpell we followed the Win Forms design, and use Dispose to know when to unhook event handlers and unregister from the adorner layer. This is also why we don't call SuppressFinalize, because what we're doing is only performing necessary dereferencing so that the GC can do it's job. Last week we fixed a bug, where the application doesn't fully close down if the user runs a dialog spell check on a textbox with no errors. I don't know if that could be related to what you're doing, but here it is the soon to be released DLL https://www.dropbox.com/.../RSWPF-3-NoErrors.zip?m
If I can help further just let me know Jim -your feedback is helpful to other users, thank you!Evaluation Downloads-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 9/14/2012
Posts: 4
|
Thanks for the updated dll. I'll try that out. Though, if you have no unmanaged resources then there should be no finalizer or you should still call SuppressFinalize on the dispose method. The issue is that the existence of a finalizer will cause the object to survive a GC and get placed on the finalizer queue along with anything it references. This means that potentially large amounts of memory will not get reclaimed until the finalizer thread is run. This can take some time as the process will keep grabbing memory until the GC heuristics decide that finalizers should be run.
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
I see what you mean, thanks - please try this build https://www.dropbox.com/...SWPF-3-Finalizers.zip?m
Jim -your feedback is helpful to other users, thank you!Evaluation Downloads-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 9/14/2012
Posts: 4
|
Thanks, this seems to reduce some of the finalizer work our app is having to do. I would suggest that you keep the finalizer and use SuppressFinalize in the dispose method however as then the finalizer will get ignored if disposed but can be used if someone forgets to dispose.
|
|
|
|
Rank: Advanced Member
Groups: Administrators, Registered
Joined: 8/13/2004
Posts: 2,669
Location: Canada
|
Thanks, but the reason we didn't go that route with this change was because the dispose/finalizer code was just unhooking handlers and the adorner, and since the finalizer can't run until the handlers are unhooked, it wasn't going to do anything anyway. So there was actually no point in having the finalizer code. Jim -your feedback is helpful to other users, thank you!Evaluation Downloads-your feedback is helpful to other users, thank you!
|
|
|
|
Rank: Member
Groups: Registered
Joined: 9/14/2012
Posts: 4
|
|
|
|
