I'm creating my own Text Editor in iOS using Core Text. Pretty much everything works great with one exception: Stuff really starts to slow down when the text document is "large". I've discovered that iOS is requesting the entire document text on every change, including selection changes (at least, when I notify the UITextInputDelegate of selection changes). Part of the problem is that I've already optimized my Core Text code by splitting up the document into paragraphs and rendering only the paragraphs that change. But doing this also split up the document string (which is a NSAttributedString) into the separate 'paragraph objects'. So when iOS requests the entire text document, I have to combine all those strings into one string, which takes time and memory.
My solution is to give iOS incorrect UITextPosition's for the beginningOfDocument and endOfDocument methods, limiting those positions to the paragraph(s) intersecting the current selection. This is actually working very well. iOS is now only requesting the current paragraph(s) of the change, which has completely eliminated the slow-down.
So far, so good, but I'm a little worried that this might break something. I've tested this a bit and nothing is broken, but Text Editors can be hard to test (who knows if it'll break in some edge condition).
I have 2 question:
Should iOS be requesting the entire document text on each change? If not, then perhaps some other method in my UITextInput protocol methods that are returning the wrong value, somehow causing iOS to request the entire document.
Does anyone know if this will actually break anything?
Alright, I've been testing this for quite a while now and I've finally found a place where using this technique will break functionality. UITextInput uses beginningOfDocument and endOfDocument to determine whether it has room to "move" when you press the arrow keys on a bluetooth keyboard. Returning only the beginning and end of the currently selected paragraph(s) cause it to ignore the 'arrow' buttons when it is at the beginning or end of that paragraph and those arrows indicate an attempt to move outside what it thinks is the beginning/end of the document. It's easy enough to fix. If the currently selection begins at the beginning/end of a paragraph, I now also return the previous/next paragraph as part of the document, respectively.
Related
While doing accessibility sanity checks, I like to ensure to provide appropriate guidance for developers to correct anything that is reported as problematic or incorrect.
In this case, their implementation of a tooltip was incorrect. So I set to use MDN's documentation (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tooltip_Role) as a reference.
But before simply sharing that, I tested MDN's code example with VoiceOver myself, and I discovered something curious:
List elements (<ul> in MDN's example) are not actually read by the screen reader. I tested with VoiceOver on Chrome and Firefox, and they both read the tooltip content as expected.
Does anyone know if this is a Safari bug, or if there is anything to ensure to do in the markup to ensure the tooltip content is read?
Here is a link to test: https://htmlpreview.github.io/?https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Here is the code: https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Edit: To clarify, I currently tested this on macOS Ventura with Safari, Firefox, and Chrome. The issue of VoiceOver not reading the content happens on Safari (weirdly enough). It skips the list altogether (I added paragraphs , <p> before and after the list to see what it would read).
There are two different situations here.
Descriptions only need to be read as a flat string
According to ARIA’s Text Equivalent Computation, exposure of the referenced structure is not required:
The purpose of the computation is to create a perceivable label or description for alternative presentations, in the form of a flat string of space separated textual tokens.
So this concerns the text read when focus is on the input—provided the user activated announcement of descriptions in their settings.
Reading the tooltips content by moving reading cursor onto it
If the reading cursor is moved onto the tooltip widget itself, the whole contents must be read, including structure. It would be surprising if Safari didn’t do that. If it doesn’t, it’s a bug.
Tooltips must stay open on hover
Both tooltip examples have one issue, though: They fail WCAG Success Criterion 1.4.13 Content on Hover or Focus, because they close when trying to move the mouse pointer on them.
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
It’s a reflex of mouse users to hover content they are reading, independent of screen reader use.
I have a program in visual basic that prints some large reports, sometimes with hundreds of pages. There is a lot of encapsulation here, but it boils down to us using the PrintDocument.Print() command to print the document. When it prints, it prints the form feed characters as up arrows (in windows 10). Is there anyway to get these to print as blanks, and just have them start a new page?
Let me know if you need anymore details. This is my first Visual Basic experience and I'm not sure what info would be useful.
Okay, I don't know if anyone else will encounter this, but I fixed it, so maybe my method will help you. There is a PrintPage event handler that fires off when you are printing, and basically it's just a matter of reading a string up to the form feed character, substringing that off to another string and then printing that other string, then culling it from the original string. Making sure you remove the vbFormFeed character from each page.
I have a document into which I copy all kinds of VBA code regarding questions asked on this site and write code in preparation for answers. This document was created on my PC (with Word 2010). It has no event procedure that runs on the Save event, but at some point a few weeks back it started to ask me the above question before every save, including automatic saves. The document is based on the Normal template which has no code in it. I don't know which code may have caused this to start, nor which code to even suspect. Other documents open in the same instance of Word save normally. It's only this one document that is affected.
The document also contains a lot of special items, like content controls, fields, ActiveX controls, EndNotes, tables and comments. I suspect the comments to be related to this problem in some way.
I know that I could probably stop the alerts by disabling alerts but that isn't what I want. I want Word to display all the normal alerts. It's just this abnormal one which I would like to switch off. Any ideas how to do that? Or what caused Word to issue that alert in the first place?
In these situations I make several backups of the document and then start looking for something that is broken. So using a new backup each time, I systematically delete portions of the document to see if the unwanted / unexpected behavior disappears. For example I first try to isolate the issue to the top of bottom 1/2 of the document. If I can establish that the issue is related to the bottom half then I delete half of the bottom half of the document and so on... it can take a while but it has been an effective method of finding issues for me.
That said, I tried this on a document recently and just ended up going round in circles. I thought I had narrowed the issue down to a single corrupt image, but that turned out to be NOT the case.
I've also found that there are some things that I can do with VBA that Word simply can NOT undo... I'm only aware of a few things (which I'd have to look up in my notes) but I'm sure there's a whole list of things.
A possible workaround might be to clear the undo history for this specific document prior to saving, I imagine that will suppress the message and save you from losing the standard notifications. Hope it helps :)
Good luck!
I am busy developing my first android app which is essentially a bubble burst type of game.
So far everything works except when I want to update a text box with a score.
Views are moved using translateanimation and all works as expected as long as a simple .setText() is not used.
When this is added occasionally some views that have been moved around previously suddenly move back to their original position. Additionally some variables also are set back to their original value.
I have tried updating the score via asyntask as well as runonuithread but the same issue occurs.
Thanks
I sorted it out.
I had the text box which I use for the score in a seperate xml and in that xml I had a include statement pointing to another xml file which had all the controls which are used as bubbles/blocks.
By including the score text box in the same xml the issue was sorted out.
There must be some rules that Android has regarding animating/updating controls across two seperate layouts.
I've created a UITextView and set the autocapitalization property to UITextAutocapitalizationTypeSentences or to UITextAutocapitalizationTypeWords. Both settings work as expected except for the first word that is typed, which is not autocapitalized! It is autocapitalized if the user deletes the text taking the cursor back to the start of the line.
My workaround would be to convert the first letter from uppercase to lowercase in the UITextView delegate method textView:shouldChangeTextInRange:replacementText:.
The only tiny issue that remains is that the user is unable to tap on the shift key to prevent the first word from capitalizing.
Do other people experience this issue and is this what you've done?
Thanks.
I think this may be an issue with the simulator. It seems to be working fine on the device!