Syntax Editor Control Crashes

Hi Paul,

We'd probably need to see a repro of it happening to determine what is going on. Can you email over a simple sample project and steps to make it occur? Please make sure not to include any .exe files in the ZIP you send over or our mail server will reject it. Thanks!

I was hoping to get a step by step means to reproduce the error and thus hadn't reported the issue. But alas I have not been able to determine a sequence of events that results in the issue.
The application has code that will on occasion update the Dynamic Syntax Language in a background thread setting the IsUpdating property before and after the code that updates any language attributes. I believe that there may be issues with cross thread locking of the language while this is occurring or synchronization issues with internal objects after the update. I experienced another crash today for a different reason than I had seen in the past (dump include below), this occurrence happened while typing in the editor just after the thread updated the language.

at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
at System.Collections.ArrayList.RemoveAt(Int32 index)
at ActiproSoftware.SyntaxEditor.CharClass.Add(CharInterval interval)
at ActiproSoftware.SyntaxEditor.CharClass.AddRange(CharClass charClass)
at ActiproSoftware.SyntaxEditor.Addons.Dynamic.LexicalPatternGroup.b()
at ActiproSoftware.SyntaxEditor.Addons.Dynamic.DynamicLexicalState.a()
at ActiproSoftware.SyntaxEditor.Addons.Dynamic.DynamicLexicalState.a(ITextBufferReader A_0, LexicalPattern& A_1)
at ActiproSoftware.SyntaxEditor.Addons.Dynamic.DynamicSyntaxLanguage.ActiproSoftware.SyntaxEditor.IMergableLexicalParser.GetNextTokenLexicalParseData(ITextBufferReader reader, ILexicalState lexicalState, ITokenLexicalParseData& lexicalParseData)
at u.a(Document A_0, TextRange A_1, Int32 A_2, Int32 A_3, ILexicalParseTarget A_4)
at ActiproSoftware.SyntaxEditor.MergableSyntaxLanguage.PerformLexicalParse(Document document, TextRange parseTextRange, ILexicalParseTarget parseTarget)
at ActiproSoftware.SyntaxEditor.Document.a(DocumentModification A_0, Boolean A_1)
at ActiproSoftware.SyntaxEditor.Document.b(DocumentModificationType A_0, Int32 A_1, Int32 A_2, String A_3, DocumentModificationOptions A_4, WeakReference A_5)
at ActiproSoftware.SyntaxEditor.Document.a(DocumentModificationType A_0, Int32 A_1, Int32 A_2, String A_3, DocumentModificationOptions A_4, WeakReference A_5)
at ActiproSoftware.SyntaxEditor.EditorView.a(DocumentModificationType A_0, String A_1, DocumentModificationOptions A_2)
at ActiproSoftware.SyntaxEditor.EditorView.ReplaceSelectedText(DocumentModificationType type, String text, DocumentModificationOptions options)
at ActiproSoftware.SyntaxEditor.Commands.TypingCommand.Execute(EditCommandContext context)
at ActiproSoftware.SyntaxEditor.MacroRecording.a(EditCommand A_0, EditCommandContext A_1)
at ActiproSoftware.SyntaxEditor.EditorView.a(EditCommand A_0, Boolean A_1)
at ActiproSoftware.SyntaxEditor.SyntaxEditor.a(EditorView A_0, Keys A_1, Char A_2, Boolean A_3)
at ActiproSoftware.SyntaxEditor.SyntaxEditor.OnKeyPress(KeyPressEventArgs e)
at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
at System.Windows.Forms.Control.WmKeyChar(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at ActiproSoftware.SyntaxEditor.SyntaxEditor.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at OrbitalServices.LextEdit.Program.Main(String[] args) in C:\VS2008\LextEdit.Net\LextEdit\Program.cs:line 309
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Hi Paul,

Yes modifying a dynamic language in a worker thread isn't a safe thing to do. You'd want to do that in the main thread if at all possible. This must be what is causing your issues.

One thing you may be able to do is if your language is only used by one language, perhaps lock the document.SyncRoot before doing changes. That may help prevent these issues from coming up since we do grab a lock on that before processing document modifications. But again, you'd have to do it on any document that could be using the language before you modify the language.

I am still having a couple issues with crashes, even with the update occurring on the main thread the control continues to crash. Locking of the editor.Document.SyncRoot has resolved the issue in the main editor but other open windows with editors using the same language are still prone to red-x's. This is as you pointed out in the previous post, but I haven't been able to figure out a way to have the language detect what objects its is being used by.

Is there a way from within the language to discover all the Syntax Editor objects that are using the language so that the language could lock each editor?

There may be another method of accomplishing what I am attempting so let me walk you through an example of a similar scenario that you might be able to comment on or suggest a different solution.

Say we are build a editor that will connect to databases and execute queries against them. In this example multiple windows against a single connection can exist, each with their own session. Languages are loaded specific to a connection so they can have independent lists of things like tables, columns etc. for colorization and intelliprompts, but the language can be shared across the multiple windows/editors that will exist for a single connection. Periodically the objects in the DB will change and the program needs to re-load those lists and update the language to effect parsing.

In a scenario similar to this I change a LexicalPatternGroup within the language to update parsing/colorization and execute an editor.Document.Reparse(). While this is crude and locking the editor.Document.SyncRoot while doing the two steps has been effective, it only really works within one editor using the language. I am maintaining the language.IsUpdating attribute around the changes but it really doesn't seam like the editors are utilizing the property.

Thanks in advance, Paul

Hi Paul,

I don't believe there is a way for a language to know which documents use it. You'd probably have to maintain some sort of registry of your own when a document started using a language and then as you update the language, lock all the related docs down, make your language changes, and then unlock the docs. That's what you'd have to do if there are multiple threads at work here.