Everything you are describing can easily be explained....
What event are you using to trigger the update of your cursor position text box? You weren't specific... but you would definitely need to be using one. The CurrentPos and/or Caret.Position properties aren't going to notify you of changes, and as a result, the value displayed there could be stale. The NativeScintilla.UpdateUI event is the correct one to be using. It is for this express purpose. The Scintilla documentation describes the event as "Either the text or styling of the document has changed or the selection range or scroll position has changed. Now would be a good time to update any container UI elements that depend on document or view state." Make sure you're using that event to trigger any updates to your position display.
As for the position value being off when you use Unicode characters such as ü', 'ä' or 'ö'... that is because those properties tell you the current byte offset, not the character offset. As you may know Unicode characters can often require more than one byte of storage. This problem is a limitation of the native Scintilla component and has been well documented in these forums. https://www.google.com/#q=Unicode+site%3Ahttp%3A%2F%2Fscintillanet.codeplex.com%2Fdiscussions%2F
Instead, try the NativeScintilla.GetColumn method. It's probably what you're looking for. Per the Scintilla documentation, "returns the column number of a position pos within the document taking the width of tabs into account. This returns the column number of the last tab on the line before pos, plus the number of characters between the last tab and pos. If there are no tab characters on the line, the return value is the number of characters up to the position on the line. In both cases, double byte characters count as a single character." (emphasis on the last line)
If that's not what you're looking for, then try some of the other suggestions in the forums to translate byte offsets to character offsets.
At this point, hopefully the bells are starting to go off and I won't need to explain why your code sample could throw an exception.
Jacob
What event are you using to trigger the update of your cursor position text box? You weren't specific... but you would definitely need to be using one. The CurrentPos and/or Caret.Position properties aren't going to notify you of changes, and as a result, the value displayed there could be stale. The NativeScintilla.UpdateUI event is the correct one to be using. It is for this express purpose. The Scintilla documentation describes the event as "Either the text or styling of the document has changed or the selection range or scroll position has changed. Now would be a good time to update any container UI elements that depend on document or view state." Make sure you're using that event to trigger any updates to your position display.
As for the position value being off when you use Unicode characters such as ü', 'ä' or 'ö'... that is because those properties tell you the current byte offset, not the character offset. As you may know Unicode characters can often require more than one byte of storage. This problem is a limitation of the native Scintilla component and has been well documented in these forums. https://www.google.com/#q=Unicode+site%3Ahttp%3A%2F%2Fscintillanet.codeplex.com%2Fdiscussions%2F
Instead, try the NativeScintilla.GetColumn method. It's probably what you're looking for. Per the Scintilla documentation, "returns the column number of a position pos within the document taking the width of tabs into account. This returns the column number of the last tab on the line before pos, plus the number of characters between the last tab and pos. If there are no tab characters on the line, the return value is the number of characters up to the position on the line. In both cases, double byte characters count as a single character." (emphasis on the last line)
If that's not what you're looking for, then try some of the other suggestions in the forums to translate byte offsets to character offsets.
At this point, hopefully the bells are starting to go off and I won't need to explain why your code sample could throw an exception.
Jacob