TrimTrailingWhitespace issue

Comments (7)

Posted 18 years ago by Kelly Leahy - Software Architect, Milliman

As a workaround, you could try saving the current document position and restoring it.

One way to get to this would be Caret.DocumentPosition. To restore it, you have to convert document position to offset and set the caret offset. You can convert the document position to a offset using the document's (or view's) PositionToOffset method.

It's not optimal, but it'd be less annoying than the caret moving to the very END of the document. It would, however, change the selection if the user had text selected (since it won't preserve the selection, I think, though I haven't tried it so it's possible the selection would stay).

If the support guys are looking for other opinions, I too believe that this method should not modify the caret or selection. In fact, I think any methods that operate on the document should not modify the selection and/or caret unless one of the following is true:

1) the user would expect the selection to change,
2) the previous selection doesn't make sense anymore.

(1) I can't think of any cases that meet this criteria, except for the really obvious ones like calls that have the word Select or something in them...
(2) examples of this case are: deleting text that contains the current selection, replacing the current selection, inserting text into the document (maybe), etc...

Again, however, I take a very conservative stance with regard to the selection being modified. I'd say unless you're POSITIVE that (1) or (2) is satisfied, the selection should NOT be modified. If it's not absolutely clear cut - don't do it. The programmer can always write an extra line of code to do the selection change if they really want it in cases where you didn't expect them to.

Good luck,

Kelly Leahy Software Architect Milliman, USA

Posted 18 years ago by Matthew Smith - Developer, One Plus One Solutions Pty Limited

Thanks for the suggestions Kelly! I'll give them a look.

Thinking about it more this morning, the document is being edited so I selection would probably be changed. I guess the main issue is moving the caret and document position - if they can stay in the same location I'm not too worried.

Regards, Matt

Posted 18 years ago by Actipro Software Support - Cleveland, OH, USA

Keep in mind that the Document.TrimTrailingWhitespace is operating on the Document and is independent of any views (since the Document model is not tied to the view model at all) so there isn't a way to internally control this in this case.

What you could do is as Kelly said, save the selected view's first visible display line index and any other related properties, then do the trim, then restore those properties. By calling SyntaxEditor.SuspendPainting and related ResumePainting later that might help prevent a flicker too. Hope that helps.

Actipro Software Support

Posted 18 years ago by Matthew Smith - Developer, One Plus One Solutions Pty Limited

Ok - thanks for the reply.

Regards, Matt

Posted 18 years ago by Kelly Leahy - Software Architect, Milliman

You could actually do my workaround for all views, couldn't you? That information is available on a per-view basis, I think???

Why, though, is the selection changing? Is it because the code that is trimming the whitespace resets the Text property of the document from scratch? It still seems like the default behavior of the view should be that it would keep the caret position the same when Text is changed unless the text change invalidates the current position (i.e. the position would no longer be within the text) in which case the caret position should default to the end of the line or the end of the document (whichever makes more sense). Notice, I'm referring to the caret position, not the offset.

I don't think this should be the behavior for "paste" operations, though. Those should work as the user would expect, changing the caret position either to the beginning of the paste range or the end (not sure which makes more sense). I don't think paste operations manifest themselves as a change in "Text" anyway, so it probably is a moot point.

Hopefully I didn't "run on" to long here, but I think I am making myself clear (I hope).

Thanks,

Kelly Leahy Software Architect Milliman, USA

Posted 18 years ago by Actipro Software Support - Cleveland, OH, USA

Yes you could do that on all views.

This is a tricky scenario. Ordinarily you do want the caret to move to the end of any sort of change. However there are certain exceptions to that rule, of which the trimming of whitespace would probably be one. The best way to handle it would probably be to use some sort of document modification option and use that option for these sorts of operations. Probably the DocumentModificationOptions.RetainSelection flag handling should be enhanced to support this.

Actipro Software Support

Posted 18 years ago by Matthew Smith - Developer, One Plus One Solutions Pty Limited

Just in-case someone else is wanting a work-around or for future reference, this is what I have come up with:


            'Prepare
            steEditor.SuspendPainting()

            'Get current document position
            Dim documentPosition As ActiproSoftware.SyntaxEditor.DocumentPosition = steEditor.Caret.DocumentPosition()
            Dim firstVisibleDisplayLine As Integer = steEditor.SelectedView.FirstVisibleDisplayLineIndex
            Dim startEditPosition As ActiproSoftware.SyntaxEditor.EditPosition = steEditor.SelectedView.Selection.StartEditPosition
            Dim endEditPosition As ActiproSoftware.SyntaxEditor.EditPosition = steEditor.SelectedView.Selection.EndEditPosition

            'Trim Trailing spaces
            steEditor.Document.TrimTrailingWhitespace()

            'Restore document position
            steEditor.SelectedView.FirstVisibleDisplayLineIndex = firstVisibleDisplayLine
            steEditor.SelectedView.Selection.StartOffset = (steEditor.Document.PositionToOffset(documentPosition))

            'Reselect text (if required)
            steEditor.SelectedView.Selection.StartEditPosition = startEditPosition
            steEditor.SelectedView.Selection.EndEditPosition = endEditPosition

            'Finalise
            steEditor.ResumePainting()

Seems to work pretty well and no noticeable issues.

Regards, Matt

The latest build of this product (v24.1.1) was released 7 months ago, which was after the last post in this thread.

Comments (7)

Add Comment