UpdateTextBox doesn't work with AutoComplete

Feb 28, 2012 at 5:46 PM
Edited Feb 28, 2012 at 6:34 PM

Something is baffling me. I can't use AutoCompleteCustomSource with UpdateTextBox. It works partially if the TextBox.AutoCompleteCustomSource is preinitialized during InitializeComponent: the Append mode works, but the Suggestion list doesn't work because when you select an item from the drop-down list, the TextBox text is not modified.

Much worse, if I set AutoCompleteCustomSource dynamically during the TextChanged or SetText events (RealTime=true), the control stops calling GetText and GetEnabled, and _firstPrecedent becomes null in _depEnabled and _depText.

Wait, I just thought of something. When AutoCompleteCustomSource is changed, OnHandleDestroyed and OnHandleCreated are called twice, during which UpdateTextBox calls  _depText.Dispose() and _depEnabled.Dispose(). Maybe Dependent.OnGet() should trace a warning message if it is called when disposed?

If I delete the calls to _depText.Dispose() and _depEnabled.Dispose(), the first problem disappears. I wonder if I should just commit this change; I assume the Dispose() calls were mainly to avoid memory leaks, and now that Precedents use WeakReferences to Dependents, it should no longer be a problem, right?

Unfortunately, a new problem appears in its place: if I modify AutoCompleteCustomSource during SetText, I consistently get "Access violation reading location 0xfeeefeee", YIKES! (my own code and UpdateControls are not on the stack when this happens, except my Main() method). If I modify AutoCompleteCustomSource during TextChanged, an access violation occurs every few keystrokes (even if I use BeginInvoke). It seems a lot of people are having the same problem:


A workaround that seems to work is to set AutoCompleteMode=None before changing AutoCompleteCustomSource, then restoring it to its original value afterward*.

Unfortunately, none of the AutoComplete modes work quite right with a dynamic AutoComplete list, although this is not an UpdateControls problem, it exists in an ordinary TextBox too. Specifically, the suggestion list won't appear at all, and the Append mode won't allow the user to delete the suggestion by pressing backspace. :( But as I mentioned, UpdateTextBox doesn't work right with a static AutoComplete list either.

*Update: this isn't reliable after all, it still can crash.

Mar 1, 2012 at 2:21 PM
Edited Mar 1, 2012 at 2:31 PM

It may be that Update Controls will schedule an assignment to the Text property whenever the text changes. Although this should be suppressed when the Modified is true and the TextBox has focused, it could be interfering.

I could have sworn that I had Dependent throw if you called OnGet after Dispose. I'll have to check that again. But you are correct about the call to Dispose being redundant now that UC uses weak references. However, if that didn't fix the problem, then I guess you don't need to commit the change.


Edit: Sure enough, it doesn't throw in MakeUpToDate if the Dependent is disposed. I think I had some extra check code in there in the past, but removed it to support more platforms.

Mar 11, 2012 at 7:51 PM

I was able to reproduce this problem in Silverlight 5. I can confirm that it is related to the fact that Update Controls delays its change notifications until after the property set.

I added a class called AffectedSet to the Silverlight 5 wrapper. This keeps track of the set of properties that are affected by the current change. Rather than scheduling these change notifications, it triggers them at the end of the property setter. This made the AutoCompleteTextBox work in Silverlight 5.

I am currently determining the best way to use this class on each platform. Unfortunately, change notification is drastically different from one platform to the next, so I have to take them one at a time. If you want to take on Windows Forms, please do so.