SyntaxEditor not thread safe - SyntaxEditor for WPF Forum

Posted 12 years ago by 7Alpha7

Version: 12.1.0560

Platform: .NET 4.0

Environment: Windows 8 (64-bit)

Hello,

I have a solution / projects based studio where I have (custom)SourceFile objects encapsulating an (actipro)EditorDocument. When I want to edit a file I use an (actipro)SyntaxEditor and I bind its Document property to the (actipro)EditorDocument of the (custom)SourceFile associated with the file. Each change in the (actipro)SyntaxEditor is reflected in the (actipro)EditorDocument.CurrentSnapshot in the (custom)SourceFile.

This works perfectly but problems arises when I want to use the (custom)SourceFile independently from an (actipro)SyntaxEditor, AFTER it has been bound once to an (actipro)SyntaxEditor. In refactoring scenario I need to modify the underlying (actipro)EditorDocument.Text and it happens in another thread. As soon as I want to use the SetText method I have this exception :

System.InvalidOperationException : calling thread cannot access this object because another thread is proprietary

 System.InvalidOperationException : calling thread cannot access this object because another thread is proprietary 

System.Windows.Threading.Dispatcher.VerifyAccess()
     à System.Windows.Threading.DispatcherObject.VerifyAccess()
     à System.Windows.DependencyObject.GetValue(DependencyProperty dp) 
    à ActiproSoftware.Windows.Controls.SyntaxEditor.SyntaxEditor.get_IsMultiLine()
     à ActiproSoftware.Windows.Controls.SyntaxEditor.SyntaxEditor.OnDocumentTextChanging(Object sender, TextSnapshotChangingEventArgs e)
     à System.EventHandler'1.Invoke(Object sender, TEventArgs e) 
    à ActiproSoftware.Text.Implementation.TextDocumentBase.OnTextChanging(TextSnapshotChangingEventArgs e) 
    à ActiproSoftware.Text.Implementation.TextDocumentBase.#O7c(#g7b textChange)  
   à #Q2b.#g7b.Apply() 
    à ActiproSoftware.Text.Implementation.TextDocumentBase.SetText(String text)

I understand the SyntaxEditor is bound to the TextChanging property of my (actipro)EditorDocument but :

- I need to use the same (actipro)EditorDocument also in another thread;
- I need to be able to use it while the (actipro)SyntaxEditor might be open;
- I want to reuse the same (actipro)EditorDocument and I don't want to be obliged to provide the (actipro)SyntaxEditor a new one because I would be obligated to bind a lot of stuff such as text changes, language, external changes, etc...

Thank you for your suggestions.

Comments (2)

Posted 12 years ago by Actipro Software Support - Cleveland, OH, USA

Hello, a document's snapshots are thread safe but doing things like setting document text won't be since as you saw, there are external UI pieces that hook up to its events.

What you need to do is do all your refactoring work in your worker threads. Then when you are ready to set the text, forward the text to the main UI thread and do the SetText call in that thread. That should get it working for your scenario.

Actipro Software Support

Posted 12 years ago by 7Alpha7

Sure I can do such thing but I won't. Imagine a refactoring scenario where a lot of different files might be involved : the refactoring thread would have to forward the SetText call in the main UI thread each time, just "in case" a SyntaxEditor might have hooked up an event. This is not good programming pattern. I don't want my working thread to be interrupted several times. And it's really ennoying to place all the SetText calls at this end of the process, because it would break the encapsulation of my algorithm pattern and force me to stack a lot of text changes somewhere. Each refactored file does the SetText call and it's the more elegant way to do. I cannot see why I would be obligated to change that just because an external UI component might have hooked up an event.

As soon as a component silenltly hook up an event of an external component only for UI purposes, I expect this component to work in the main UI thread itself !

So the thing I will probably be obligated to do is to let the SyntaxEditor work with its default Document and I will pass it the Language of CodeDocument, then I will inform the SyntaxEditor of the external changes myself and I will pass by the SyntaxEditor text changes to the CodeDocument. There will be UI calls only when the SyntaxEditor will be linked to the refactored file and encapsulation will be safe.

The latest build of this product (v24.1.2) was released 2 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.