Hi Rick,
We haven't had any reports of this. When it happened, was there any stack trace or was it purely outsite of .NET altogether? If it was purely outside of our code, it's not likely something we can fix and would need Microsoft to fix whatever they changed. I'd recommend trying to run your app in debug mode with break on exceptions set on so you can get as much exception info as possible and let us know what you find.
Do you have steps we can use to repro it within our samples?
Here's the thing... the app doesn't crash when run within Visual Studio, reagarless if I'm running a Debug version or a Release version. I only experience the problem when running the .exe directly (e.g. not from within VS). I've also determined that an .exe generated without compiler optimizations (e.g. Debug version) runs just fine outside of VS, but one compiled with Optimizations enabled crashes. The same Release .exe will run fine within VS but crash when run directly.
So what I've done is started up the app, attached to it in VS, opened a file to make it crash, and looked at the stack trace. I repeated this several times using the exact same steps and noticed that the crash doesn't always occur in the same part of the code, e.g. the traces are different. And because the code is optimized, VS doesn't give much information. I have one of the stack traces that I can send you, if you want to look at it.
I also tried to create this in the sample app, but wasn't able to. I'm not really sure where to go from here...
I was able to find a resolution to the problem. I knew that the crash always happened in the same function of the application (opening a new file for editing). Between that, the nature of the exception, and the stack trace, I narrowed my focus to a specific set of functions within the application. I modified the call that creates a new DocumentWindow instance (which hosts SE), to pass objects ByRef rather than ByVal. .NET 4.5.x seems to like this better...
We've run into this as well; our XP users are reporting the same bug. We haven't tried Erel's optimization solution.
Has this been addressed in the latest release?
Hi Ben,
We never got a sample project showing the issue, so we haven't done anything specifically for this. The other customer said that compiling with optimizations disabled solved it, which makes me think that the bug might not be in our C# code itself. I would recommend trying with the latest version to see if it still happens there.
If I use GetSubstring() to request text with a specific LineTerminator does it apply to ALL the text or just to text that is not within quotes?
I was assumming it applied to all text since quotes may not always denote strings but I wanted to check.
A user has reported \r characters causing problems for them even though I select the string using the CarriageReturn option.
I thought that meant it would return only \n at the line ends and therefore there could not be any \r characters in the string.
Hi Mike,
When you use the overload of GetSubstring that takes in a LineTerminator, all the lines in that substring will end with the line terminator you specify. But note the CarriageReturn value is \r. Newline is \n.
Hi,
we stumbled upon another threading-issue within our test suite. It seems that the editor instance is disposed on the main thread, while the parser thread tries to update the automatic outlining. In our case it is in combination with the C# language add-on, but the problem applies to all languages with automatic outlining.
It isn't easy to reproduce, but never the less the access to variables that are used in different threads should be synchronized. Additionally we are going to wait for the parser thread, before we call dispose to avoid any other unforseen problems.
Exception message: System.NullReferenceException: Object reference not set to an instance of an object. at ActiproSoftware.SyntaxEditor.Document.PerformAutomaticOutlining(TextRange parseTextRange, AutomaticOutliningBehavior behavior, DocumentModification modification, Boolean isProgrammaticTextReplacement) at ActiproSoftware.SyntaxEditor.Document.#AAh(ISemanticParseData value, TextRange parseTextRange, Boolean isProgrammaticTextReplacement, Object requestSyncRoot) at ActiproSoftware.SyntaxEditor.Document.#fAh(SemanticParserServiceRequest request) at ActiproSoftware.SyntaxEditor.SemanticParserService.#Jth(SemanticParserServiceRequest request) at ActiproSoftware.SyntaxEditor.SemanticParserService.#Kth() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart()
Hi Tobias,
We do have some thread sync code in there, but I see one thing that could be improved. Which version are you using, is it the latest v14.1.0322 as your post indicates?
We are using the build 320, but I've checked all changes in 321 and 322. The problem remains the same. The PerformAutomaticOutlining method is called in the parser thread and the dispose is called in the main thread. During the dispose the language is set to null. It is not enough to check the reference for null, since this isn't an atomic operation. You could copy the reference via Interlocked.Exchange() but the best way is really to use locks. The dispose call should wait if the PerformAutomaticOutlining method is running and vice versa if the dispose call came in first.
Hi Tobias,
The reference copy was what we were thinking could be improved there. Ordinarily I would also agree that a lock could be added to Dispose but I am hesitant to add that since it is a Dispose method, which could be called by the developer or system. I worry that a lock there could cause stability issues in the framework in certain scenarios, so we will add the reference copy within PerformAutomaticOutlining.
Yes, I think that will work. My only concern is that everyone who handles the AutomaticOutliningComplete event and the method SyntaxLanguage.OnDocumentAutomaticOutliningComplete(). Both need to know that the caller might already be disposed and check that accordingly. But thats something we can work with.
I am a user for Actipro WPF.
Is there a way to use the source code of a implemented Grammar class for Actipro WPF in Actipro Winforms, or convert it for Actipro Winforms?
It does not exist the ActiproSoftware.Text.Parsing.LLParser Namespace in Actipro Winforms.
Do I have to create Ast tag blocks for Actipro Winforms?
Hi Roger,
The LL(*) Parsing Framework from the WPF version is newer than the WinForms SyntaxEditor API, so it isn't really compatible wth the WinForms SyntaxEditor. We would ideally like to backport the newer, better WPF version's API to the WinForms version so that we can get WinForms on par with the other three platforms SyntaxEditor is on in terms of capabilities.
The LL(*) Parsing Framework heavily relies on the classes defined in the Text assembly. Even if you did execute the WPF versions parser from WinForms, the resulting parse data would contain an AST that isn't compatible with the WinForms AST. You'd then need to recurse through the tree and create a compatible copy. All in all, I'm not sure it's worth the effort to do this right now.
I'm trying to prevent my software from changing focus to the menu bar upon release of the Alt key after a block selection using the SyntaxEditor. The demo SDI editor seems to not have this problem... Anyone have any ideas?
Hi Michael,
What sort of menu control are you using here? Is it a third-party one? Perhaps you could track SyntaxEditor's KeyUp event and if the mouse's left button is down while Alt is being released, set e.Handled = true? Perhaps that would help prevent the menu control from getting it.
Is it possible to change the width/height of the scrollbar used by the text editor?
Thanks,
Dan
Any plans to implement a sublime text like code map (the zoomed out view of the source code that acts as a scroll bar)? Any pointers on how to do this?
Thanks,
Dan
Hi Dan,
Sorry but the WinForms version of SyntaxEditor internally arranges them using the SystemInformation.HorizontalScrollBarHeight and SystemInformation.VerticalScrollBarWidth system properties. There unfortunately isn't a way to change that.
We don't have plans for that in the WinForms SyntaxEditor. You could possibly override renderer methods that draw the scrollbars to do custom rendering for the scrollbars. To get a general idea of the code appearance, you could iterate the document tokens when drawing the scrollbar. My only concern would be that for larger documents, this could be a performance drag.