Recommended way to perform longer background checking on the AST?

I was playing around with spawning a background thread in the IParser.Parse method to look at the AST, and add errors.  However, the UI doesn't update with the red squiggles when I do in the additional background thread that was spawned in the IParser.Parse.

public override IParseData Parse(IParseRequest request)
{
	var results = base.Parse(request) as ILLParseData;

	BackgroundWorker worker = new BackgroundWorker();
	worker.DoWork += (sender, e) =>
	{
		// do extra AST validation here	and add to results
		// squiggles dont appear :-(
	};
	worker.RunWorkerAsync();
	
	return results;
}

 If I can do something like this, the original parse will do its thing, and report on grammar issues quickly and provide local variables etc..

Is this the recommended way?  

That won't work as-is because the built in error squiggles only update when the Document.ParseData changes at the end of a parsing operation.  But here you are asynchronously updating the parse data at some later time after the above already occurred. 

If you could run the logic currently in the BackgroundWorker synchronously from within your IParser.Parse method, then the error results would all come though ok without any additional effort.

But you've said you want to offload that work in a delayed way.  In you must do that, you could probably set the document.ParseData to a new changed value (maybe a clone of your original parse data but with additional info) after your secondary parse occurs, and that would tell the ParseErrorTagger to refresh.

All that being said, I'm not sure I like the whole concept of this async parse within an async parse.  What you will end up with is parse data after edits that first has some data, but not the secondary parser's results.  And then that secondary parse data result drops in again later, only to be replaced after another edit by the simpler parse data results and so on.  It seems like it opens the door to problems with consistency.

I agree.  Is there a more recommend way to offload the "longer" validation efforts?

For your longer running validation, you could possibly maintain a separate ISquiggleTag tagger (above and beyond the normal ParseErrorTagger) that would specifically track those validation errors.  When your validation completes, you could get the tagger and update it appropriately.  See our AdornmentsIntraTextNotes QuickStart's MainControl code-behind for an example of retrieving a custom tagger.

Your tagger could either:

1. Be a CollectionTagger<ISquiggleTag> and you update its contained results.  Any updates will automatically raise the TagsChanged event.  If you are making multiple changes, call the tagger.CreateBatch method to create an IDisposable result you can put within a using statement wrapper around your changes.
2. Be a normal tagger that would know how to look somewhere else, like in the document's parse data, to find these long-running validation errors.  Then raise the TagsChanged event appropriately.

When the tagger raises the TagsChanged event, the editor would know to watch for its tags to render more squiggles.  

Thanks for the information.

With the tagger, is that done async?  How does the tagger work when newer parse results are coming in?  

And what does the syntaxeditor look like when thats happening? (in terms of .. does lines of code flash the squiggle when the new parse comes in, and doesnt have any validation on those long validation?)

Also, if I use the tagger, how can I collect all the errors (the normal grammar errors, and these new errors that the tagger is finding) when I need to report these errors to the user?

While you can do all the work to generate the additional validation errors on a worker thread or async, I'd suggest that you dispatch and update the secondary squiggle tagger for those errors in the main UI thread.  That will prevent any cross-thread exceptions.

When TagsChanged events fire for taggers, it will invalidate the view lines that cover the invalidated tag range.  The view line invalidation triggers a measure/arrange request and the view will refresh itself when the WPF dispatcher sends the layout calls.  There shouldn't be any flicker.

I would suggest that you stick with the normal ParseErrorTagger for normal grammar syntax errors, or any errors that always come back in the normal "first pass" of your parsing.  Any errors for the secondary extended validation should be tagged with the secondary tagger instead.