In XCode 7.3, document items (toggled with ctrl-6) is not displaying properly beyond a certain point. (There is nothing wrong above the screen shot)
Not many people will experience this since it happens (as far as I've found out) in specific situations.
let i = 0
switch i {
default: "\(i) ©"
}
Copy and pasting the above code will make the same thing happen in any file with // MARK: // FIXME: // TODO: code markings.
The condition for this to happen is the combination of the three:
Using switch: if {} won't cause the same problem.
Using string interpolation: String(format: "%d ©", i) or "stringText ©" won't cause the same problem.
Using Emoji & Symbols with a space in front: "\(i)©" won't cause the same problem.
Any one of the three conditions are not met, the bug won't happen. So in case you look at document items a lot and don't want to see the mangled dropdown list, try changing any one of three conditions.
Related
I'm trying to implement a syntax-coloring text editor that also does things like insert whitespace at the start of a new line for you, or replace text with text attachments.
After perusing the docs again after a previous implementation had issues with undoing, it seems like the recommended bottleneck for this is NSTextStorageDelegate's textStorage(_,willProcessEditing:,range:,changeInLength:) method (which states that Delegates can change the characters or attributes., whereas didProcessEditing says I can only change attributes). This works fine, except that whenever I actually change attributes or text, the text insertion mark moves to the end of whatever range of text I modify (so if I change the style of the entire line, the cursor goes at the end of the line).
Does anybody know what additional call(s) I am missing that tell NSTextStorage/NSTextView not to screw up the insertion mark? Also, once I insert text, I might have to tell it to move the insertion mark to account for text I've inserted.
Note: I've seen Modifying NSTextStorage causes insertion point to move to the end of the line, but that assumes I'm subclassing NSTextStorage, so I can't use the solution there (and would rather not subclass NSTextStorage, as it's a semi-abstract subclass and I'd lose certain behaviours of Apple's class if I subclassed it).
I found out the source of the problem.
And the only solution that will work robustly based on reasons inherent to the Cocoa framework instead of mere work-arounds. (Note there's probably at least one other, metastable approach based on a ton of quick-fixes that produces a similar result, but as metastable alternatives go, that'll be very fragile and require a ton of effort to maintain.)
TL;DR Problem: NSTextStorage collects edited calls and combines the ranges, starting with the user-edited change (e.g. the insertion), then adding all ranges from addAttributes(_:range:) calls during highlighting.
TL;DR Solution: Perform highlighting from textDidChange(_:) exclusively.
Details
This only applies to a single processEditing() run, both in NSTextStorage subclasses and in NSTextStorageDelegate callbacks.
The only safe way to perform highlighting I found is to hook into NSText.didChangeNotification or implement NSTextDelegate.textDidChange(_:).
As per #Willeke's comments to the OP's question, this is the best place to perform changes after the layout pass. But as opposed to the comment thread, setting back NSText.selectedRange does not suffice. You won't notice the problem of post-fixing the selection after the caret has moved away until
you highlight whole blocks of text,
spanning multiple lines, and
exceeding the visible (NSClipView) boundaries of the scroll view.
In this rare case, most keystrokes will make the scroll view jiggle or bounce around. But there's no additional quick-fix against this. I tried. Neither preventing sending the scroll commands from private API in NSLayoutManager nor avoiding scrolling by overriding all methods with "scroll" in them from a NSTextView subclass works well. You can stop scrolling to the insertion point altogether, sure, but no such luck getting a solid algorithm out that does not scroll only when you perform highlighting.
The didChangeNotification approach does work reliably in all situations I and my app's testers were able to come up with (including a crash situation as weird as scrolling the text and then, during the animation, replacing the string with something shorter -- yeah, try to figure that kind of stuff out from crash logs that report invalid glyph generation ...).
This approach works because it does 2 glyph generation passes:
One pass for the edited range, in the case of typing for every key stroke with a NSRange of length 1, sending the edited notification with both [.editedCharacters, .editedAttributes], the former being responsible for moving the caret;
another pass for whatever range is affected by syntax highlighting, sending the edited notification with [.editedAttributes] only, thus not affecting the caret's position at all.
Even more details
In case you want to know more about the source of the problem, I put more my research, different approaches, and details of the solution in a much longer blog post for reference. This here, though, is the solution itself. http://christiantietze.de/posts/2017/11/syntax-highlight-nstextstorage-insertion-point-change/
The above accepted answer with the notification center worked for me, but I had to include one more thing when editing text. (Which may be different from selection).
The editedRange of the NSTextStorage was whack after the notification center callback. So I keep track of the last known value myself by overriding the processEditing function and using that value later when I get the callback.
override func processEditing() {
// Hack.. the editedRange property when reading from the notification center callback is weird
lastEditedRange = editedRange
super.processEditing()
}
While setting up an NSAlert object to be displayed as a modal sheet in Xcode 5.0.2, I hit an interesting surprise.
I was planning on using beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo:
As I started to enter it, Xcode autofilled beginSheetModalForWindow:completionHandler: for me (even though I cannot find this in any NSAlert documentation).
I prefer to use completion handlers rather than delegate/selector as a callback mechanism, so I went ahead and tried it. I was pleasantly surprised to find that it worked perfectly.
Three quick questions before I commit to this.
Am I missing something in the documentation?
Is it "safe" to use this feature if it is undocumented? (i.e. will it magically disappear as mysteriously as it appeared?)
I'd rather not hardcode the response values based on what I'm seeing via logging. Does anybody know the "proper" NS...Button constants?
This call is “safe” but it’s 10.9+ only. Here it is from the header file:
#if NS_BLOCKS_AVAILABLE
- (void)beginSheetModalForWindow:(NSWindow *)sheetWindow completionHandler:(void (^)(NSModalResponse returnCode))handler NS_AVAILABLE_MAC(10_9);
#endif
It appears they just accidentally left it out of the current docs. The headers are generally considered the “truth” in Cocoa, though—they authoritatively tell you what’s deprecated and what’s new. (Unlike in X11, for instance, where the documentation was declared to be correct over the actual implementations or the headers.)
These are the constants you want to use inside your completionHandler block:
/* These are additional NSModalResponse values used by NSAlert's -runModal and -beginSheetModalForWindow:completionHandler:.
By default, NSAlert return values are position dependent, with this mapping:
first (rightmost) button = NSAlertFirstButtonReturn
second button = NSAlertSecondButtonReturn
third button = NSAlertThirdButtonReturn
buttonPosition 3+x = NSAlertThirdButtonReturn + x
Note that these return values do not apply to an NSAlert created via +alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:, which instead uses the same return values as NSRunAlertPanel. See NSAlertDefaultReturn, etc. in NSPanel.h
*/
enum {
NSAlertFirstButtonReturn = 1000,
NSAlertSecondButtonReturn = 1001,
NSAlertThirdButtonReturn = 1002
};
Automatic indentation in my Xcode sometimes comes out wrong. I can't see any rhyme or reason to when it is correct and when it isn't. Here is a typical case where Xcode got it wrong. Selecting and asking Xcode to re-indent does not help. Of course I can fix it manually. But it would be much better to fix whatever is wrong with my Xcode.
Any successful experiences out there?
-(UIFont*) font {
UIFont* actual = self.actualFont;
if (actual) {
return actual;
}
WJStyleSheet* sheet = self.styleSheet;
UIFont* r = sheet.font;
return r;
}
Does code completion still work completely. Can you for example type self.actual and then hit CTRL + SPACE and get a coloured code completion suggestion with the class next to actualFont? If not then I think this is related to the code completion which can get corrupted in Xcode.
I could fix this using the following answer: https://stackoverflow.com/a/8165886/784318
I have two basic practical problems:
1) The first one is really stupid. I receive a message saying: "Method definition for 'aIncreasedSelection' not found, together with an "Incomplete Implementation".
Well, that is quite strange, because I don't have this method in neither my .m or .h file (and the class name is mentioned in the remark).
I used to implement this method, but I deleted it because it was redundant. In a certain way, it appears as if my Xcode project can't let go of the method...
2) The second question is also a very mysterious one. I have a couple of viewControllers in which I have put the identical same background, and the identical same buttons. It's really identical in size and position in the screen as well (I defined the pixels). For an unknown reason, when I switch between the views, one of the buttons changes very slightly its color (it is a Photoshop created button with mirror effect on the bottom, it's the mirror that becomes lighter). That is really annoying because it's supposed to be identical; when the user switches views now, he can see that there is a color difference in the button (supposed to be planted as a button in a dock, which should be identical over the entire app)...
Very frustrating as I cannot solve these small mistakes... Any ideas? Thanks!
Regarding your first problem, if you have verified that it no longer exists in your .h or .m file, try to cmd+shift+k and clean your project, then rebuild. This should update everything and in theory solve that issue for you.
As for the second problem, it sounds strange indeed. Is there any chance you could provide pictures somehow? Are you statically loading the image into similar buttons, or are you doing something differently?
Re - opening my project solved my first problem (unlike the refresh - cmd + shift + k, which didn't work). The color problem is not solved despite :-/
It was definitely a bug since I didn't change anything. It is in fact - very confusing!
I have a single line CEikLabel in my application that needs to scroll text.
The simple solution that comes to mind (but possibly naive) would be something like..
[begin pseduo code]
on timer.fire {
set slightly shifted text in label
redraw label
}
start timer
[end pseudo code]
Using a CPeriodic class as the timer and label.DrawDeferred() on each update.
Do you think this is the best way, it may be rather inefficient redrawing the label two or three times a second.. but is there any other way?
Thanks :)
I've seen the timer based solution used for scrolling item names in listboxes.
A couple of things to watch out for are that it could flicker a bit while scrolling and that you need to make sure the text you put on the label is not too long, otherwise it will automatically clip the string and add an elipsis (...)
Use TextUtils::ClipToFit to get a string that fits on the label and remove the elipsis it adds before putting the text on the label (search for KTextUtilClipEndChar in your clipped string). You will need to work out how many characters to skip at the beginning of the string before passing it to the clip function.
I don't know whether there is another way to do it and can't say whether the approach you have in your mind will be inefficient. However, you may want to take a look at this thread which discusses pretty much the same question as yours and also briefly mentions somewhat the same solution as the one you have conceived of.
I have done it like this
TTimeIntervalMicroSeconds32 scrolltime(70000);
iPeriodicScroll = CPeriodic::NewL(CActive::EPriorityIdle);
iPeriodicScroll->Start(scrolltime, scrolltime, TCallBack(CVisTagContainerView::ScrollTextL, this));
and then in the repeated function
CEikLabel *label = iContainer->Label();
const TDesC16 *temp = label->Text();
if (temp->Length() <= 0) {
if (iTextState != ETextIdle) { return; }
DownloadMoreTextL();
return;
}
TPtrC16 right = temp->Right(temp->Length()-1);
label->SetTextL(right);
label->DrawDeferred();
So text moves right to left, and when all gone, the label is repopulated by DownloadMoreTextL