I am currently using iOS 8's provided keyboard extension's textDocumentProxy.documentContextBeforeInput to get the text that a user has entered in order to perform some sort of modification to it.
I noticed that while the method documentContextBeforeInput would work fine for any chucks of texts, as soon as periods "." are inserted, documentContextBeforeInput is only able to return text that occurs after the period.
For example, testing the following text: "This is sentence 1. And this is sentence 2" When using documentContextBeforeInput with placing the cursor at the end, it will only return "And this is sentence 2", and not the entire text that has come before it.
Has anyone also encountered this issue, and if so have you discovered a workaround?
Thanks!
Related
I have a label which shows the pink area on the screen. However, the word "gender " is not shown in the top line even if it has enough space. Why is it not showing up in the first line itself? What I need
label.text = #"Do you believe in gender equality";
Label
The UILabel is working as intended by preventing an orphaned word so it’s more readable. This was introduced in iOS 11. Apple must disable it for iMessage because they probably intend this behaviour for long articles of text, not text messages.
I've seen fixes including
call sizeToFit on the label after the text has been set
setting UserDefaults.standard.set(false, forKey: "NSAllowsDefaultLineBreakStrategy") // Using this private tricky shortcut may leads appstore rejection.
But none of these are working on iOS 13, simulator (Not tested on devices).
Fix
One tricky solution is - append some spaces or two tabs("\t\t") to the text and set programatically.
Use following code:
label.lineBreakStrategy = []
On iOS 10 in a UILabel, the letter יִ (a yud with a chirik under it) is getting displayed as a circle instead of the way it's supposed to appear.
Other vowels and letters (e.g. יֵ יַ יֶ יֹ) are being displayed ok.
I submitted this as a bug to apple (bug id 28561355 on https://bugreport.apple.com).
Even if apple can fix this in a future version of iOS, is there anything I can do now, to hack this to work? I can just replace the yud-chirik with a plain yud, but I'd rather try and keep the display as it's supposed to be.
Thanks.
UPDATE: It seems that if I change the font to the default apple font (instead of a custom font that I was using), then the yud-chirik appears, but the chirik appears in the wrong place. It appears directly under the yud instead of at the bottom with all the other vowels.
I was wondering how WhatsApp handles the time shown in every message.
For those who don't know:
If the message is very short, the text and time are in the same row. (tine in the end of row)
If the message is long, the time is in the bottom right corner - the text wrapped around it.
if you have some idea how to do it please let me know
Here is the requested screenshot (please ignore checkmarks):
You can use a single attributed string with different text attributes for the main message, and the timestamp. iOS will then internally do all this for you automatically.
Otherwise you can use exclusion paths which are a part of TextKit.
When I write arabic text containing the letter kasra (unicode character 0x650, phonetic equivalent i) to a button, the kasra is not displayed. Thus, the word mumkin appears as mumkn. If I inspect the NSString in Xcode, the kasra is present, but the kasra is not displayed in the iPhone simulator or on a real iPad. The other two short vowels (fatha and damma) are displayed correctly.
The arabic letter kasra (unicode character 0x650) is missing from all of the built-in IOS7 fonts that i have tried.
The solution was to build a different font into my app- I used AGA-Rasheeq-Bold.
This may be a bug. I just tried it in the storyboard editor and it does not seem to work. I created a string in the MAC Notes application, copied and pasted. It displays correctly in the left hand properties panel, but not in the button itself. Could you provide the exact Unicode string? You may need to open a bug report with Apple.
I can confirm that it works correctly in a Label field, but not a Button (IOS 6.1 and Xcode 4.6.3)
Try attributed text. This seems to work around the issue.
I've got two UITextViews containing data that should be recongised by the data detection, however whilst one works fine on both device and simulator there's one that only works under Simulator. I've attempted trashing the build from my device, cleaning the product down, removing derived data and nothing seems to resolve the inconsistency.
Link detection was enabled within Interface Builder, the data is passed in with a NSString stringWithFormat: formatted string and set with UITextView setText:. Set the same way for both, so there's no difference there, but it just doesn't seem to work correctly for one of them.
EDIT: On the device if I tap on one of the items that should detect as a link, it'll then turn blue and do link detection. I'm not setting any custom fonts or colours that could have an impact.
It appears that the trick is to setScrollable:NO. Seems to fix the problem, although if you need scrolling, I'm not sure what the answer will be...
Apparently this issue is caused by how iOS is currently handling the UITextView links. It is creating an NSAttributedString that turns sections of the text blue ( when the view contains a link ). So I've figured out that this bug only occurs when a link is the first text in the AttributedString, i.e. the first text in the text view. So it's easily fixed by prepending an whitespace to your text before setting it. Or overriding setText to " " + text;
Hope this helps guys