Outlining lost if multi-line comment used above a node

Hi Karl,

Unfortunately it isn't possible right now. Basically when you create the comment, you are wiping out all the other nodes below, therefore losing any state they had. So when it does the reparse, we don't know what the state of the nodes was.

I tried the same thing in VS 2005 and it is unable to do it either.

I suspected as much.

I guess I could manually store state information about each node so that if the nodes are wiped out then I could retrieve the state details from the stored details.

Is there an outlining.nodes collection or another way that I can get the list of current nodes in a document?

Thanks,

Karl

You can get editor.Document.Outlining.RootNode which gives you the root node of the document and then you'd have to recurse through the node tree from there.

Thanks for that.

I now see how to get hold of each of the nodes however I'm completely blank on how to go about this.

I've tried to handle the key_typed event for the editor and am checking the token key to see if it is the start of a multi-line comment. If it is, then I intend to store the node states.

However, the GetTokenOutliningAction in the SemanticParser fires before the key_typed event and clears out all of the nodes before the key_typed event.

I thought I'd try my check within the SemanticSQLParser class but I can't see my document from in there so I cannot get at the nodes.

Obviously I'm going about this in the wrong way but I'm at a loss as to where to go from here.

Any help would be appreciated.

Thanks,

Karl

Hi Karl,

I think KeyTyped is probably the wrong place to do this... There is KeyTyping which happens before typing affects the document by the way.

Probably it's better to make a semantic parser that implements PreParse and PostParse. Do you saving of data there perhaps?

I do worry that what you are trying to do might affect performance, which is probably a reason Microsoft didn't implement it in VS. However if you can get it working, then more power to you!

Thanks for the pointer to PreParse. I'd spotted PostParse but it didn't occur to me to check for a PreParse.

You're quite right about the possible negative effect on performance but I won't know until I try and it's one of those things that I've just got to try and get working.

Currently, if I've collapsed a bunch of nodes and I'm editing part of the document above these nodes, anytime a start a StringStartToken the nodes are lost and it's a bit frustrating (but nothing I can't live with if I have to).

Hmmm, just had a thought.

If there was a DocumentOutliningNodeClick (or MouseUp) event I could store node state details at that point. Then if there was a also DocumentOutliningNodeCreated event, when the nodes get recreated I could check to see if that created node was one of my stored nodes and if so retrieve its state.

What I don't know is whether it's possible to expose a NodeClick and NodeCreated event. But if it were easily possible then that would be really cool.

Anyway, just a thought. I'll try out using PreParse like you suggested but I suspect you're right about the performance.

Karl

There is a SyntaxEditor.DocumentOutliningNodeExpandedChanged event. Actually some of the stuff we're doing for v4.0 might help out with this issue. Because we have the capability of delaying outlining until after you stop typing in rapid succession. So if you type a string fairly fast with out stopping in the middle, then the nodes might not change state. This is all still work in progress though.

Another thing is that you can make your strings end on line ends as well as quotes. That will help right now.

I had thought about ending my strings on line ends. Unfortunately I'm using SyntaxEditor for T-SQL langauge, which allows commands (and strings) to span multiple lines.

Can't wait for version 4.0. I better stop posting as I don't want to distract you from finishing off v 4.0 :).

Karl

I've struck the same problem. A proper solution that perhaps adds a lot of logic to the PreParse, PostParse and GetTokenOutliningAction is difficult to see but something that I'm probably going to have to attempt. This will wait for V4 which sounds like it could help a lot.

In the meantime, I have a suggestion for a work-around. Consider typing something like an opening quote or block comment start as the beginning of a 'rip'. What you can do is place a 'rip stopper' at places in your code. This will prevent the rip from propagating too far. Folding that is after the rip stopper will be left alone.

So what is a 'rip stopper' ? How about the string "-- ' -- */" (without the double quotes of course). Normally this will be seen as a single line comment and ignored. Add an opening quote before it and all of the text in between becomes a comment and loses its folding. However the rip stops at the new quote. The rest of the rip stopper becomes another spurious line comment.

Similarly if you start a block comment the second section of the rip stopper comes into play.

It is mildly annoying and quite a kludge to add these lines but you can decide where and when to do it. You can for example place it after the terminating ";" for each SQL statement. Thus I habitually use "; --' -- */" in non-trivial SQL coding.

This idea comes from something else that I do out of habit. Whenever you want to block comment out a section of code, use "--*/" as the block end. Then to put the code back in you just change the block beginning from "/*" to "--/*". In effect using a line comment to remove the block comment start.

This way you don't have to also go and remove or re-add the block end whenever you want to toggle the block comment.

Hope this helps.

Paul

Hi Paul,

Thanks for the suggestion. As you say, it's a bit of a kludge but it works. Problem is that I cannot expect all my users to remember to do this everytime they come to write a string or block comment. But it's better than nothing.

Like you I'm going to try to implment a proper solution, although I suspect that the large amount of logic that would need to go into the SemanticParse will probably render the solution a slow one.

Exposing a couple of events for the OutliningNode would by provide a more robust (and easier) solution I think. Not sure if this will make it into v4 (but it would be great if it did - hint, hint).

Currently, DocumentOutliningNodeExpandedChanged fires when the NodeExpanded changes through programmatic or user interaction. If there was a DocumentOutliningNodeClick event, node state details could be stored at that point. A DocumentOutliningNodeCreated event would then let you apply previous saved node details if there are any.

Thanks,

Karl