Outlining Persistence

I agree. This is a feature I haven't attempted to implement yet in the current version, but I know I will eventually. Having built-in support for saving/restoring the outlining state would be a great addition to the control.

Question... is this feature requested for a scenario where you have a single editor instance and swap documents in and out of it. Then once the editor instance closes, you no longer care about maintaining this information?

How I would use it would be when the user closes a file, I would at that point save the outlining state to a repository I maintain that would link the file and the outlining state. Then, if the user opened that file again I would get the outlining state out of the repository and try to apply the last outlining state to the file that was just loaded.

If the file had changed in any way, I would be ok if the outlining state just returned and did not set the state. After thinking about it it should be fairly simple to just store the outlining tree and expanded/collapsed and then when reapplying, if the tree matches what was saved after the file is loaded, then it could just go through and expand/collapse outline nodes.

Thanks

To answer the question posed by Actipro Support, I think this type of persistence would be needed in both situations.

I remember you saying before that you're working on a solution to have the same editor control capable of "swapping" displayed documents. Persistence of the entire document should be maintainable if you swap to another document and then later come back to the same document.

This outlining information would also be useful for saving a file and then later re-opening the file (even after an editor application has been closed and reopened). I believe most users of an editor with outlining capability would like the option of being able to persist the outlining information even when the file is saved and later reopened.

Actually we're working right now on a lot of internal updating of our object model for SyntaxEditor. We've been doing a lot of work on the past couple months finalizing the design for our WinUICore framework and are retrofitting the changes into SyntaxEditor. The end result will be tighter, better designed internal code. Only a few changes to the public object model should be noticable.

One of the things we're also doing is trying to add that feature where a Document can be swapped in and out of a SyntaxEditor instance. So that should handle the one case.

I'll add the save/load feature to the TODO list.

That sounds great. If you could support XML for the save/load data, that'd be even better. I'm looking forward to the next release.

Is there any chance, that the Save/Load feature for outlining is goinf to be implemented in a short-term maintenance release? If not, I'm afraid I'll have to implement it myself. Any suggestions or sample code?

It probably will not be short-term. You're better off making that on your own for now.

The OutliningNode structure is simply a tree structure so you can make your own tree objects that store information so that you can identify each outlining node and whether it was collapsed.

I was looking at this thread and wondering if there have been any updates as it relates to saving the state of the outlining? The thread started about a year and half ago and I was hopefully this feature made it into the current version.

Hi Ted,

We haven't implemented it yet however that is probably something we can do for our 4.0 version. We're trying to tackle as much of the TODO list as possible for 4.0.

Any timeframe available yet for when 4.0 will be available? The new parsing sounds like exactly what I'm needing to improve performance of some items I have.

Thanks,

Ashton

No timeframe but it's our top priority and we're working hard on it. Right now working on core code to build abstract syntax trees and then hopefully hook that up to update the outlining in a document.

Ashton, you are on our advanced customer beta tester list so we'll let you know as soon as there's something that we can have you try out privately. We tore apart code for 4.0 and have been making improvements in almost every feature area. We still need to get some basic things functioning and working together again and then we'll contact you.

Working with version 3.1.203, I've run across this same need just recently. So in trying to preserve the OutliningNodes myself, I thought I could iterate over the whole node tree. The documentation says that each OutliningNode has an Item property that contains the node's children. However, this doesn't actually exist in the API for that version. What am I to do? Thanks.

EDIT: my bad. using GetEnumerator() to access the children. sorry.

[Modified at 06/01/2006 12:40 PM]

EDIT2: GetEnumerator on RootNode doesn't ever get me anything. Please advise. (also posted in "Outlining.RootNode Invalid" thread)

[Modified at 06/01/2006 12:56 PM]

UPDATE:
Ah, I see now. The outlining must be being cleared when we do a lexical parse, then filled when we do a semantic parse. I'm doing a full reparse so by the time we call PreParse(...), the RootNode is empty. I just need to save my OutliningNode info sooner.

I apologize for throwing a hissy fit.

[Modified at 06/01/2006 01:16 PM]

Yes if doing a full reparse, it will clear the nodes. But if doing an incremental parse, it won't.

The "Item" property by the way is for VB. That means indexer in C#.

Have there been any changes to the way outlining works since this posting?

My problem is that the application I've written allows for user-defined identifiers in the language. When the document is parsed to update the highlighting of these identifiers, then something happens which I don't want to happen-->the outlining is also updated--all sections expand without the user wanting them to expand.

The outlining can be saved and restored, but then the screen flashes when this is done.

Thanks for any input you may have.

(Using v4.0.257)

I have a similar language. It sounds like in your situation you might be performing 2 semantic parsing passes: the first is normal, then the 2nd to find the user-defined keywords. I am doing everything in 1 pass, and don't get any screen flashing, no outlining nodes that quickly expand then collapse again, or any other graphical glitches.

I wrote our semantic parser using the Grammar Designer, giving all potential user-defined identifiers a specific token via the lexical parser. Then I handle the Document.SemanticParseDataChanged event.

In there, I iterate over all of the tokens, looking for my special token, and seeing if it represents a user-defined keyword. If so, I change the token's id (I derived from MergableToken so that I could do this). This bit of code must be in a try-catch because it is not thread safe. After all that, I call document.InvalidatePaint() to refresh the syntax highlighting for any token id's I changed.

In the end, I did not have to do anything with saving and restoring the outlining info (although I am doing this between sessions with the application).

Let me know if you would like to see some sample code.

That sounds really interesting. Do you allow for an infinite number of possibilities for user-defined keywords, created on the fly? This is what is going on in my application--and the keywords are added to the language programmatically as a new LexicalPattern. If you are doing pretty much the same thing, I'd love to see some sample code to see how you're handling it. Thanks!

Hi Barry,

What you're describing sounds different to me than Adam's scenario. For Barry, I believe you said you are probably doing IsUpdating=True then making changes to your language to support the new keywords and setting IsUpdating=False again. That triggers a complete reparse and therefore perhaps you lose the state of the outlining nodes. Do I understand correctly?

However Adam's implementation ideas might be a good solution for you.

[Modified at 10/31/2007 01:05 PM]

I'm doing it a bit differently than you, Barry. Our language's user-defined keywords are identified in our Document.SemanticParseDataChanged event right before we fix up the token ids like I described earlier. I've also written our own Lexical Parser, so we're not using the LexicalPattern stuff. Isn't that for dynamic languages (aka, defined by an xml file)?

Yes, you have my scenario correct.

IsUpdating=True then making changes to your language to support the new keywords and setting IsUpdating=False again. That triggers a complete reparse and therefore perhaps you lose the state of the outlining nodes

The complete reparse is what the customer wants, with an infinite number of possible user-defined keywords.

Everything was fine except for losing the outlining node state. I was wondering if there were a way around this?

Thanks,
Barry

I have a structure that stores the StartOffset, EndOffset and Collapsed/Expanded state for an Outlining Node.

So before doing anything that is going to blow away the current Outlining state (setting IsUpdatting or calling SyntaxEditor.Document.Reparse()), I recursively iterate over the SyntaxEditor.Document.Outlining.RootNode and its children, collecting the data into a list of the aforementioned structures.

After my work is completed, if the OutliningMode is Automatic, all I have to do is use the OutliningNode.FindNodeRecursive(...) function to match up my data with its OutliningNode and set OutliningNode.Expanded. If it is Manual, I use Document.Outlining.Add(...) to create the node, then set OutliningNode.Expanded.

I use this same functionality to remember the outlining information for each file in between sessions with my application.

Hope that helps.