Text x-thread error with grid on multiple windows on unique threads

Posted 1 month ago by Avatar Darcy Davidson


I am getting a cross thread access exception (on a textbox) when I set the DataObject on the property grid.  It occurs only when I spawn each WPF parent window on a new thread, like so:

Dim newWindowThread As Thread = New Thread(New ThreadStart(Sub()
Dim w As New Window1()
End Sub))
newWindowThread.IsBackground = True

Window1 just has a property grid on it, and on the loaded event I set the DataObject to a simple test class with a single integer property.  The first instance does not error, but the 2nd instance does.

[Modified 1 month ago]

Comments (4)

Posted 1 month ago by Actipro Software Support - Cleveland, OH, USA

Hi Darcy,

If you are having a PropertyGrid instance work on a data object from another thread, I could see that causing this kind of error.  UI controls generally can only work on data in their same thread.

If it's something else and you only have each PropertyGrid editing objects in their same thread, then we'd need a sample project from you to debug with.  In that case, please make a new simple sample project that shows it and send that to our support address.  Exclude any bin/obj folders from the ZIP you send and rename the .zip file extension so it doesn't get spam blocked.  Then we'll have a look to see what's causing it with that, and use it to ensure any changes we make fix the problem for you.

Actipro Software Support
Posted 1 month ago by Darcy Davidson

Thanks, sample project sent to support email.

Posted 1 month ago by Actipro Software Support - Cleveland, OH, USA

Thanks for the sample.  It took a while because VS didn't provide much to go on, but we narrowed it down a Style we set on the TextBox in the value template so that it's ContextMenu has a SelectAll option.  Normal WPF TextBox context menus don't have a "Select All" menu item and we wanted to ensure our editors had one. 

To do this, we effectively set a ContextMenu instance on that embedded TextBox via a Style.Setter.  While it normally works great, it seems to be bad in this case because of the multiple threads and the ContextMenu Setter fails when on a different thread than the first UI thread.  Unfortunately there doesn't seem to be a way to alter the default on-the-fly context menu that TextBox generates, other than to specifically set a ContextMenu instance.

To work around it for most properties, you'd have to set the PropertyGrid.DefaultStringValueTemplate property to:

	<TextBox Text="{Binding ValueAsString, Mode=TwoWay, ValidatesOnExceptions=True, ValidatesOnDataErrors=True, NotifyOnValidationError=True, Converter={StaticResource NoOpConverter}}" 
				IsReadOnly="{Binding IsReadOnly}" Style="{StaticResource {x:Static themes:SharedResourceKeys.EmbeddedTextBoxStyleKey}}"

The only change in the above from the default is the Style property going right to the base Style instead of the one that set the ContextMenu.

The DefaultBrushValueTemplate, DefaultColorValueTemplate, and DefaultExtendedStringValueTemplate properties are also affected but those use more complex DataTemplates.  We can send those to you offline (via the ticket system) if you use Brush, Color, or extended string properties.  It looks like the edit boxes in our Editors product also do the same thing with setting the ContextMenu in a Style.Setter.

We had to spend a while looking for a true workaround since it's not possible to intercept the built-in TextBox context menu and other workarounds we thought of had various drawbacks.  I think we finally have a good workaround ready to go for the next build now though, and it works with your sample scenario.

Actipro Software Support
Posted 1 month ago by Darcy Davidson

Your team provides the best support of anybody we deal with.  Thanks!

Information The latest build of this product (2018.1 build 0670) was released 7 days ago, which was after the last post in this thread.

Add a Comment

Please log in to a validated account to post comments.