On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: > Could you post a test file somewhere? I just tried creating 187 pages of > repeating ACCGACTACCGACT in TextEdit and it worked fine.
Thanks for your interest! I've put an example at http://www.duke.edu/~dls36/nstextview_problem/ Remember, you have to start typing somewhere in the sequence itself to see the problem that I get with TextEdit (OSX 10.6.4). If you don't see the unresponsiveness that I see, I'd be *very* interesting in exploring why... Dave On Jul 13, 2010, at 2:38 PM, Ross Carter wrote: > On Jul 12, 2010, at 6:01 PM, David Swofford wrote: > >> I'm beginning the conversion of a scientific app from Carbon to Cocoa, and >> have run into a problem with NSTextView. FWIW, I have it embedded in an >> NSScrollView that is in turn included as an HICocoaView in a Carbon window >> (but I don't think this is relevant to my problem). It works, but I've run >> into a glitch that I can't figure out how to solve. In some cases, I need >> to be able to edit files containing DNA sequences that look like this: >> >> sequence-name-1 ACCGACTACCGACT... >> sequence-name-2 GACCACTGACCACT... >> >> The number of characters in the sequences may run into the tens of >> thousands, with no spaces or other word breaks. >> >> If a file like this is opened in TextEdit (or my program, or Smultron, or >> TeXShop, or apparently any other NSTextView-based editor with the exception >> of SubEthaEdit) and I try to insert a non-space character into the middle of >> the DNA sequence, a painfully long pause (e.g., 30 sec) ensues (with a >> spinning cursor) before the character appears on the screen and the app >> becomes responsive again. Inserting the character into sequence name or the >> intervening whitespace works normally, as does inserting a space character. >> >> Spin Control indicates that all of this time is being spent in >> doubleClickAtIndex (called from NSTextView >> insertText:replacementRange:_markTextEditedForRange). I can't figure out >> why the typing of a character causes doubleClickAtIndex to be called, but I >> wouldn't care if I could just get my editor to stop going AWOL. It does >> seem like typing a character triggers some kind of word-boundary >> recalculation that is horribly expensive if the "word" is thousands of >> characters long. >> >> I've tried every NSTextView setting I can think of, and that's when I >> started looking at other editors to see if they had the same problem as I >> was having, and they did (except for SubEthaEdit). >> >> Is there anything obvious that I might be doing wrong? The fact that the >> same problem happens in TextEdit as well as several other editors suggests >> that it's a general problem, but the observation that SubEthaEdit *doesn't* >> have this problem indicates that there is something I could do to fix it--I >> just don't know what. >> >> Any ideas? I'm really frustrated by this. > > Could you post a test file somewhere? I just tried creating 187 pages of > repeating ACCGACTACCGACT in TextEdit and it worked fine. > -- David L. Swofford david.swoff...@duke.edu Center for Evolutionary Genomics Institute for Genome Sciences & Policy Box 90338 Duke University Durham, NC 27708 USA National Evolutionary Synthesis Center (NESCent) Suite A200 2024 W. Main Street Durham, NC 27705 USA (919)613-7458 (Duke) (919)668-4591 (Nescent) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
