I have a class that inherits from NSTextView, which, when initialized, sets up auto spell checking with setContinuousSpellCheckingEnabled(true) and when focused, sets itself as the first responder. Based on all the questions and answers I've seen on SO so far, it seems this should be enough to ensure the spell checker works properly.
But when I type gibberish into the view, it won't underline any misspelled words unless the word was typed relatively quickly. That is, when I type "asdf" with a space after it in under about a half of a second, the spellchecker underlines it properly. But if I type "asdf" any slower, or even if I rapidly type "asdf" but wait a second before adding a space, no underline will be shown on the word.
This leads to the possibility of the same word typed multiple times having conflicting spelling evaluations, shown below.
There was even one time during testing where I saw a red underline appear for a split second, and then immediately disappear from a misspelled word I had typed.
Also worth noting is that if the focus leaves and reenters the text view, after about 1 second after focus all the squiggly underlines appear in the correct spots under all the misspelled words. Proceeding to type additional text, however, still raises the problem I mentioned above.
This means that misspelled words will not be underlined unless
They are typed unreasonably quickly
They had been typed into the text view prior to focusing the view
As I said before I have looked at all relevant SO threads, and I have also played around with the calls to makeFirstResponder() and setContinuousSpellCheckingEnabled() extensively, and I've just about run out of ideas.
Quick update, since last week I've tried a few more things, one of which shows promise. Using the TextView function setSpellingState, I am able to programmatically force the red squiggly underline to appear anywhere within the TextView that I please. Although this seems promising, using this function has instead uncovered another buggy behavior: When I call this function and make a red squiggly appear somewhere in the view, the squiggly line will only appear briefly. The squiggly red underline appears, and after roughly the same amount of delay as I saw inthe "asdf" bug, the squiggly line disappears. This leads me to think that the problem might be caused in the C# code that overrides some of the Cocoa API.
Is this an OSX issue? Why is something as arbitrary as the speed at which I type the determining factor for whether the spell checker will correctly underline a word?
P.S. The code is in a syntax different from Objective-C syntax because I am using MCocoa, which is a tool that machine-generated wrappers for the Cocoa API. The C# code that I am currently using to reference NSTextView was generated from the MacOSX 10.5 SDK
When using setSpellingState, the squiggly line would sometimes appear and immediately disappear because of a race condition between setSpellingState and the auto spell-checker. It seems like if they both tried to highlight a word at the same time, they would cancel each other out. Since the auto spell checker's behavior is what's causing this whole problem in the first place, I just replaced setContinuousSpellCheckingEnabled(true) with setContinuousSpellCheckingEnabled(false), preventing the auto spell checker from interfering with my own implementation. Now the red squiggle underline appears correctly, no matter how I type the word! As long as it's misspelled of course :)
For anyone having issues with NSTextView's auto spell checker, I was able to simply disable the auto spell checker using setContinuousSpellCheckingEnabled(false), and hacking in my own automatic spell checker using NSSpellChecker.shared() to check for misspelled words, and setSpellingState to force-draw the red squiggly spelling indicator under the misspelled words founds by the NSSpellChecker. All this was done within the implementation of textViewDidChangeSelection, so that words could be checked every time the selection was changed by either typing, moving the cursor from an incomplete word, or pasting text.
Related
I want to create a custom breakpoint type that will break for a duration then continue. I can mark a breakpoint as this new custom type with a command in its context. Is it possible to change the red glyph of the breakpoint to one that is blue or maybe even a different shape? I cant find any literature about it anywhere. I think I could make a custom text view port adornment for a separated breakpoint marking column but things would be less complicated if I could just change the glyph. I am working with wpf. Thanks in advance.
Turns out that this is possible with the IGlyphFactory.
Read this to see how its done.
https://learn.microsoft.com/en-us/visualstudio/extensibility/creating-an-extension-with-an-editor-item-template?view=vs-2019
So here's the issue, i've removed just about everything i've found in the program- but i can not figure out for the life of me how to remove the useless whitespace that was where the line numbers were, which is completely irrelevant to me, you are basically losing 1/8th of the entire screen to useless whitespace in this IDE, and i'd like to remove it, but i dont see a setting for it, does anyone know where it is ? - basically you can see on the red lines what i mean to remove, also does anybody know how to remove the blue little extra bar? Also useless to me. Thankyou to whoever can point me to a setting where i can switch off this and retrieve some of my lost screen real-estate.
That area is for the Intellisense "Hint" icon, the track changes, selection margin, and indicator margin. Those settings are found by opening Tools > Options > Text Editor > General:
Here is what my IDE looked like before deselecting them:
And then after:
I've implemented "ChangeCase" keyboard shortcut (like Shift+F3 in MS WORD) for RichTextBox, which changes the text either selected by mouse, or the last word before caret's position. The problem is, it SOMETIMES loses the selection, or moves the caret one word left.
Once it changes the textcase without this changing of caret position, then it never changes the caret position (propably some WPF's internal caching.), so it can only happen the first time i run this function to a portion of text.
The code used is the solution mentioned in here WPF Flowdocument "change case" feature .
One problematic section of code is certainly
end = this.CaretPosition;
EditingCommands.MoveLeftByWord.Execute(null, this);
start = this.CaretPosition;
this.CaretPosition = end;
However I have no idea why it only occurs sometimes and how to fix this.
I thing it has something to do with the execution speed of this Execute() method and some side effects, because at my WPF app it only happens sometimes, but when hosting this WPF control in Winforms, moving the caret one word left happens all the time (if I hold Shift+F3, the cursor moves word by word to the very beginning of the document)
Other problem can be related with changing text of a TextRange, which is resulting in losing the selection? But again, it doesnt happen all the time and I have no clue how to fix it.
Any ideas?
I ended up with 2 options, ignoring this error or implementing the
MoveLeftByWord
logic manully without touching the
CaretPosition
I want to achieve "Virtual Space" functionality, similar to one in Visual Studio, in AvalonEdit.
I.e. the caret could be positioned beyond the end of the text line, and if you press any key, there would be spaces automatically added to match.
I am very used to this feature, but neither Googling nor studying AvalonEdit's code gave me any clues on how to enable it, if it is supported at all.
If it is not, suggestions how to extend caret handling mechanisms would be nice.
Thanks!
Edit:
Virtual space support has been added to AvalonEdit in version 4.2.0.8283.
Set textEditor.Options.EnableVirtualSpace = true;.
Below is my original answer.
It's not currently supported.
If you want to try adding it, make sure you read the "coordinate systems" documentation (in the help file on CodeProject). You'll want to extend the "visual column" so that positions after the line end are valid. And you'll have to adjust the position<->column calculations (VisualLine.GetVisualColumn and friends). Use TextView.WideSpaceWidth to figure out the columns past the end of the line.
The above should allow you to use the mouse to place the caret in virtual space. After that, you'll need to change the caret movement (arrow keys, CaretNavigationCommandHandler) and text input logic (TextArea.PerformTextInput) to also support the virtual space.
And if you're successful with the above steps, don't forget to contribute your changes back to AvalonEdit. :-)
While I'm not a fan of virtual space myself, we need something like it to make the RectangleSelection work properly.
After certain R#-recommended edits R# colors the background of blocks of code in a light royal blue and also places a mark next to the scroll bar with the same color. It is not an error or even a suggestion. It seems to be a temporary flag that clears if you close and reopen a file.
Steps to recreate:
Write a line of code like: string str = string.Format("{0}", 1);
Notice that R# will mark the str var with a light gray because it is never used.
Press Alt+Enter on the variable and select Remove Declaration from the R# context menu
See the line of code turn light royal blue...
Hover your cursor over the scroll bar marker, all you see is the code...
Does anyone know the meaning/usefulness of this "flagging"?
EDIT: My Resharper version is 4.5 running in VS 2005
I've verified the behavior that you're seeing in R# 4.5 VS 2008 (build 4.5.1274.1). I've gone through the ReSharper specifc colors in Tools->Options->Environment->Fonts and Colors and found this to be "ReSharper Highlight". I searched the ReSharper defect tracking for "remove declaration" and found this report:
RSRP-68435
A "remove declaration" fix appears for
the declaration of test. Selecting
this removes the declaration, but ends
up coloring the then and else clauses
of the if statement blue and adds blue
bars to the error strip.
The Jetbrain's answer is:
This fix works as designed. Removing
declaration can break code, so all
broken usages highlighted and you can
navigate them and fix or remove code.
Only simple expressions are removed
automatically (strings, numbers).