Discussion:
How to insert text programmatically into NSTextview??
(too old to reply)
Rich Warner
1998-03-08 20:03:12 UTC
Permalink
Hi -

Been through the text overview document, plus the NSText, NSTextView,
and NSTextStorage docs. Having a problem inserting text programmatically
into an NSTextView.
I have an NSScrollView from IB (thus it should automatically be
initialized with the necessary underlying objects). I'm trying to use it as
a status window, and thus need to write msgs to it programmatically.
Here is what I gleaned from all the docs:

theStorage = [theTextView textStorage];
[theStorage beginEditing];
[theTextView insertText:myString]; //An NSString
[theStorage endEditing];
[theTextView didChangeText];

`This produces a run-time error (quite lengthy one, actually) about
how I'm trying to modify the text without the necessary beginEditing and
endEditing pairs. ?? Anything I'm missing here?
There are a number of methods for manipulating a "marked region." Not
sure how a marked region is different from a selected region. For the above
approach, I'm assuming that the insertion point always simply stays at the
end of the text. Thus newly inserted text is appended. I don't see
specific methods for manipulating the insertion point, but could try,
"marking" all of the existing text. ??



Best regards,


R.D. Warner, owner
Perceptual Research Ventures

1.970.416.7466
***@prv.com
http://www.gj.net/prv/ NOTE: This site is being reorganized
Rich Warner
1998-03-10 12:43:47 UTC
Permalink
Explictly set the insertion point before each insertText, and forget about
the beginEditing/endEditing...
(I've added my own category on NSTextView to handle appending for me..
Hmmmm. You know, I tried simply using insertText and assuming insertion point
would remain at end of text. Kept getting lengthy error msg about how I
needed to have the beginEditing/endEditing pair.

In the NS3.3 world the way one appended was as follows:

1) Get length of text
2) Select all text from index "length" to index "length. This effectively
selected the null terminator, since the null terminator was not included in
the integer returned by the length method.
3) Replace the selection with your new string
4) ScrollSelToVisible

At least that was one way of doing it. Probably others. Certainly no simple
"append" method, though.

I tried doing the Rhapsody equivalent of this approach and that is when I
got the error msg about needing the beginEditing/endEditing pair mentioned
above.
Also got an error msg relating to out of bounds on a string object. In
Rhapsody there does not appear to be a simple "length" method, so I did a
selectAll, then queried for the range of the selection.
Perhaps the NSRange.length returned regarding the selected text *includes*
the null terminator. ?? This might explain the indexing error. Will try
the same approach listed above but modified so the indexing reflects this
possibility.

Are steps 1 & 2 above what you are referring to when you say, "Explicitly
set the insertion point" between insertText statements? I don't see any
methods for manipulating the insertion point programmatically.



Best regards,


R.D. Warner, owner
Perceptual Research Ventures

1.970.416.7466
***@prv.com
http://www.gj.net/prv/ NOTE: This site is being reorganized
Tomi Engel
1998-03-13 15:22:05 UTC
Permalink
Post by Rich Warner
1) Get length of text
2) Select all text from index "length" to index "length. This
effectively selected the null terminator, since the null terminator was
not included in the integer returned by the length method.
3) Replace the selection with your new string
4) ScrollSelToVisible
At least that was one way of doing it. Probably others. Certainly no
simple "append" method, though.
The MiscKit had a category which offered a simple append:.
Btw.. this is what categories are great for...provide shortcuts for
actions which you are combining and a number of places out of the existing
"low level" methods. (Check the Mikes MOKit for lots of addinitos to the
Openstep TextView)
Post by Rich Warner
I tried doing the Rhapsody equivalent of this approach and that is when
I got the error msg about needing the beginEditing/endEditing pair
mentioned above.
Also got an error msg relating to out of bounds on a string object. In
Rhapsody there does not appear to be a simple "length" method, so I did
a selectAll, then queried for the range of the selection.
Openstep is a bit more complicated since now you have the seperate
storage which is basically the place to modify the text...you now have a
true model-view-controller approach.
Besides that a very "tricky" part is that you still have the NSText which
NSTextView inherits from...but at least on OS 4.2 there is no online Docu
for NSText...so you have to look up the methods in the header or the
Openstep spec.
Many of the more familiar methods are in the NSText base class but work
for NSTextView as well !

Apart from that the "new" length method goes like this:

[[textView textStorage] length]
Post by Rich Warner
Perhaps the NSRange.length returned regarding the selected text
*includes* the null terminator. ?? This might explain the indexing
error. Will try the same approach listed above but modified so the
indexing reflects this possibility.
As Mike already explain here some time ago...the length does not really
refer to visible chars. So you should be careful able "optimizing" given
counts.
Post by Rich Warner
Are steps 1 & 2 above what you are referring to when you say,
"Explicitly set the insertion point" between insertText statements? I
don't see any methods for manipulating the insertion point
programmatically.
Insertion works for me with this simple piece of category code:

@implementation NSTextView (MiscExtensions)

- (void)appendString:(NSString *)aString
{
[self replaceCharactersInRange:NSMakeRange( [[self textStorage] length], 0 )
withString:aString];
}

@end



Braketing calls to appendString with begin/editEdinting, as far as I
understood it, is mainly to make the layouting process more efficient and
keep all the parts coordinated (the NSTextView system is doing some
background processing during the text load process and that like...so it
sure is more secure to do the editing calls...but its not required for
adjusting the content).

Hope this helped a little.

Aloha
Tomi

P.S. But there are (at l[east in OS 4.2) some big bugs in the NSTextView
system when it comes to reusing a TextView for different storages etc.
I'm not sure it they are still in RDR1 but they kept me busy on 4.2. So if
things don't work check if that TextEdit example code uses a different
approach then what you are trying to do.
Art Isbell
1998-03-13 19:09:43 UTC
Permalink
Post by Tomi Engel
Openstep is a bit more complicated since now you have the seperate
storage which is basically the place to modify the text...you now
have a true model-view-controller approach.
Besides that a very "tricky" part is that you still have the NSText
which NSTextView inherits from...but at least on OS 4.2 there is no
online Docu for NSText...
Just to correct what seems to be an error, on-line
documentation for the abstract NSText class is included with OS/Mach
4.2, OSE 4.2, and Yellow Box/Windows DR1 in the usual file system
location:

<nofill>
/OPENSTEP_4.2_DEVELOPER/NextLibrary/Frameworks/AppKit.framework/Versions/B/Resources/English.lproj/Documentation/Reference/Classes/NSText.rtfd
Post by Tomi Engel
[[textView textStorage] length]
</nofill>

My reading of the new text documentation suggests that
dropping down to the various "Model" classes isn't necessary in most
cases. Seems like the following would work fine:

<nofill>
[[textView string] length]
Post by Tomi Engel
@implementation NSTextView (MiscExtensions)
- (void)appendString:(NSString *)aString
{
[self replaceCharactersInRange:NSMakeRange( [[self textStorage] length], 0 )
withString:aString];
}
@end
</nofill>

Shouldn't this be a category on NSText but with [[self string]
length] used to find the string length? When a text object in a
scroll view is pulled off of the IB DataViews palette, if the text
object is configured not to accept multiple fonts, the text object
created at run-time is an NSCStringText, not an NSTextView object,
despite the IB inspector being named "NSTextView Inspector". If you
then send appendString: defined in the above category to this text
object, you'll get an unimplemented message error which can be very
confusing. In fact, if you invoke any method defined in NSTextView to
this text object, a run-time error will occur.


Apple needs to clarify this situation because it may be making
using the new text classes seem more difficult that it really is.
NSText, not NSTextView is the root abstract class of the new text
architecture. Concrete objects may not be NSTextViews so assuming
that they are will cause run-time errors.

<nofill>
Post by Tomi Engel
P.S. But there are (at l[east in OS 4.2) some big bugs in the
NSTextView system when it comes to reusing a TextView for different
storages etc. I'm not sure it they are still in RDR1 but they kept me
busy on 4.2. So if things don't work check if that TextEdit example
code uses a different approach then what you are trying to do.
</nofill>

Could this be due to your assumption that text objects are all
NSTextViews?

<nofill>
Art Isbell NeXT/MIME: ***@lava.net
IDX Systems Corporation Voice/Fax: +1 808 394 0511
(for whom I don't speak) Voice Mail: +1 808 394 0495
Healthcare Info Technology US Mail: Honolulu, HI 96825-2638</nofill>
Tomi Engel
1998-03-14 15:46:24 UTC
Permalink
Post by Tomi Engel
Besides that a very "tricky" part is that you still have the NSText
which NSTextView inherits from...but at least on OS 4.2 there is no
online Docu for NSText...
Just to correct what seems to be an error, on-line documentation for the
abstract NSText class is included with OS/Mach 4.2, OSE 4.2, and Yellow
/OPENSTEP_4.2_DEVELOPER/NextLibrary/Frameworks/AppKit.framework/Versions/B/Resources/English.lproj/Documentation/Reference/Classes/NSText.rtfd


I double checked and found that the problem I had back then was that
NSText's docu did/does not show up in the find panel if you search for
NSText. So if you have a method you're interested in you had to dig out
the docu by hand from somewhere in the filesystem.

So you are right...the file is there. But PB does not know about it for
some reason (bad preindexing I guess)

Another Problem was/is that PB also could not properly display the docu
for things like NSAttributedText (the superclass of NSTextStorage) since
it always comes up with the Appkit additions but not the base docu text.
PB couldn't handle category docu properly under Openstep.
<nofill>
Post by Tomi Engel
[[textView textStorage] length]
My reading of the new text documentation suggests that dropping down to
the various "Model" classes isn't necessary in most cases. Seems like
[[textView string] length]
Ok...this should be equivalent. Same as:

[[[textView textStorage] string] length]

</nofill>There are many different ways to get to the same result, but as I said
below some seemed buggy in 4.2, so if things don't work you might have to
try a different route until things are fixed.

<nofill>
Post by Tomi Engel
@implementation NSTextView (MiscExtensions)
- (void)appendString:(NSString *)aString
{
[self replaceCharactersInRange:NSMakeRange( [[self textStorage] length], 0 )
withString:aString];
}
@end
Shouldn't this be a category on NSText but with [[self string] length]
used to find the string length?
Yep...that would be a more general solution.
</nofill> But maybe someone from Apple (Mike?) could clarify this. I seem to
remember some remark (by Ali?) that NSText is mainly for
backwardscompatibility and should not be used in new applikations. While
it makes sense to me it would be nice to know if that is an "official"
coding rule.
<nofill>
When a text object in a scroll view is
pulled off of the IB DataViews palette, if the text object is configured
not to accept multiple fonts, the text object created at run-time is an
NSCStringText, not an NSTextView object,
I didn't know that.
Apple needs to clarify this situation because it may be making using the
new text classes seem more difficult that it really is. NSText, not
NSTextView is the root abstract class of the new text architecture.
Concrete objects may not be NSTextViews so assuming that they are will
cause run-time errors.
</nofill>

Clarification would definitly be a good thing. Especially since I lived
under the impression that NSText was for "Openstep-Spec" reasons only.

<nofill>
Post by Tomi Engel
P.S. But there are (at l[east in OS 4.2) some big bugs in the
NSTextView system when it comes to reusing a TextView for different
storages etc. I'm not sure it they are still in RDR1 but they kept me
busy on 4.2. So if things don't work check if that TextEdit example
code uses a different approach then what you are trying to do.
Could this be due to your assumption that text objects are all
NSTextViews?
</nofill>

Nope...not that one. I tried to replace an existing text storage with a
new one and ran into some crasher (range problems). And a second bug was
related to the creation of text storage instances. One of the documented
ways just didn't work in 4.2 (initWithString ??... I would have to dig
out my bug reports). The attribute handling of NSTextStorage is a little
strange in 4.2 as well since the "fixing" process corrupted the ranges.


Aloha

Tomi
Art Isbell
1998-03-14 18:52:45 UTC
Permalink
Post by Tomi Engel
I double checked and found that the problem I had back then was that
NSText's docu did/does not show up in the find panel if you search
for NSText. So if you have a method you're interested in you had to
dig out the docu by hand from somewhere in the filesystem.
So you are right...the file is there. But PB does not know about it
for some reason (bad preindexing I guess)
Another Problem was/is that PB also could not properly display the
docu for things like NSAttributedText (the superclass of
NSTextStorage) since it always comes up with the Appkit additions but
not the base docu text. PB couldn't handle category docu properly
under Openstep.
Interesting. I use HeaderViewer to view documentation under
Mach (not available on Rhapsody, I believe), so have never had that
problem. NSText documentation is available in HeaderViewer. I
typically view documentation under OSE's PB by keeping documentation
for the various object kits that I'm using open but minimized.
Because documentation is in Windows Help format, I can find
documentation for the entire kit is available if I open documentation
for just one class.


I just checked PB under OSE 4.2 and verified that its find
feature doesn't find the documentation for NSText as you point out,
but it doesn't find NSTextView either! So something is broken.

<nofill>
Post by Tomi Engel
But maybe someone from Apple (Mike?) could clarify this. I seem to
remember some remark (by Ali?) that NSText is mainly for
backwardscompatibility and should not be used in new applikations.
While it makes sense to me it would be nice to know if that is an
"official" coding rule.
</nofill>

I believe NSCStringText, not NSText, is the compatibility
class for the old NS Text class. But I wonder why NSCStringText is
still being used in the text object in IB's DataViews palette? Maybe
Apple just hasn't had time to update this or maybe this isn't true for
YB.

<nofill>
Art Isbell NeXT/MIME: ***@lava.net
IDX Systems Corporation Voice/Fax: +1 808 394 0511
(for whom I don't speak) Voice Mail: +1 808 394 0495
Healthcare Info Technology US Mail: Honolulu, HI 96825-2638</nofill>
Mike Ferris
1998-03-15 19:09:06 UTC
Permalink
I hope people aren't getting discouraged as they read this thread. Yes,
the Yellow Box text system is quite complex if you want to learn the
whole thing. However, most people don't have to learn the whole thing
and we have tried very hard to make it simple to do simple things while
keeping it possible to do really advanced and tricky things.

Also, some of the confusion in this discussion has arisen from the fact
that many people had come to know certain idioms and usage patterns of
the older class NSCStringText which the new text system replaces. In
some cases, trying to apply those old patterns to the new classes makes
things seem more difficult and complicated thanb they really are. For
instance, with the old system you really had to set a selection in order
to remove or replace text. This is no longer tru, and in fact, you
shouldn't change the selection in order to make programmatic changes
(like appending text).

So, if you're reading all this and thinking it sounds confusing, don't
despair. Chances are you won't have to deal with a lot of these issues.


Now, on to muddy the waters further. :-)
Shouldn't this be a category on NSText but with [[self string] length]
used to find the string length? When a
text object in a scroll view is pulled off of the IB DataViews palette,
if the text object is configured not to
accept multiple fonts, the text object created at run-time is an
NSCStringText, not an NSTextView object,
despite the IB inspector being named "NSTextView Inspector". If you
then send appendString: defined in
the above category to this text object, you'll get an unimplemented
message error which can be very
confusing. In fact, if you invoke any method defined in NSTextView to
this text object, a run-time error
will occur.
It should NOT be the case that you can ever get an NSCStringText off the
palette in IB. If it is, it's a bug. Please report it, if this is
happening to you. It should not matter whether you configure it for
rich text or not.

Also, I recommend never using an NSCStringText object unless you
absolutely have to. This is, for the most part, an obsolete class (just
look at its nasty name :-).

NSText exists purely for OpenStep-spec reasons. It is not that
important anymore in my opinion. It was there to define a common subset
API between the old NSCStringText and the new text system. The idea was
that an OpenStep app that used NSText exclusively would get an
NSCStringText on OpenStep implementations that did not include the new
text system, but would get the new stuff if it was there. The NSText
API is really pretty minimal though, and any sophisticated app is going
to eventually want to use API specific to the new text system (or the
old one...)
Does this apply to attributes changes as well? I change the text color
attribute in
textView:willChangeSelectionFromCharacterRange:toCharacterRange: and
the color change appears
immediately without sending scrollRangeToVisible: (well, the text that
is visible changes color
immediately anyway :-)
NSLayoutManager is lazy. It will, eventually, get around to laying out
and causing the display of any changes to the backing store. But
without a specific reason to do so, it will do it in the background when
it gets a chance.

You can always force layout to occur synchronously by asking the
NSLayoutManager a question that requires layout to be done up to a
certain point in order to get an answer. The reason that
-scrollRangeToVisible: will cause layout to be done immediately is
because it must ask the NSLayoutManager where in the view the range lies
and to answer, NSLayoutManager will have to have current layout
information at least up to the end of the range.

Any change initiated from the UI will cause synchronous layout up to at
least the end of the selection, and will therefore cause the immediate
display of the new layout up to that point. This is because the
user-action type methods in NSTextView are implemented to do that
explicitly.

When you change the color in your selection change notification handler,
if your change occurs in the range of the old or new selection, it will
get laid out and displayed as a side effect of the fact that when the
selection changes the NSTextView wants to ensure the redisplay of the
new selection. Or if you're changing attributes on a range downstream
from the selection change activity it could be that the background
layout happens quickly enough that it looks like its synchronous.

If you change the text directly in the backing store and it isn't in
response to other stuff going on in the NSTextView that causes
synchronous layout and display, and you want your changes visible
immediately, you will have to arrrange for it yourself.


I notice there's also some confusion about the doc. Here are the
classes which play a major role in the new text system and what
framework they reside in. Spec sheets for all these classes should be
there.

NSString/NSMutableString - Foundation
NSAttributedString/NSMutableAttributedString - Foundation (with
extensions in AppKit)
NSTextStorage - AppKit
NSLayoutManager - AppKit
NSTextContainer - AppKit
NSText - AppKit (abstract base class for NSTextView)
NSTextView - AppKit
NSTextAttachment - AppKit
NSTextAttachmentCell - AppKit

Everyone should learn about NSString whether you're going to use the
text system or not. If you're going to use the text system for anything
but the most simplistic situations, you'll want to familiarize yourself
with NSTextView and NSTextStorage (including the API they inherit). You
probably don't need to worry about NSLayoutManager or NSTextContainer or
the NSTextAttachment stuff unless you're doing pretty advanced stuff.

Also, please take a peek at the Text System Overview documentation. It
provides a pretty good introduction to the way the text system works.

Mike Ferris
Marco Scheurer
1998-03-16 12:53:39 UTC
Permalink
Post by Mike Ferris
I hope people aren't getting discouraged as they read this thread. Yes,
the Yellow Box text system is quite complex if you want to learn the
whole thing. However, most people don't have to learn the whole thing
and we have tried very hard to make it simple to do simple things while
keeping it possible to do really advanced and tricky things.
There's something in the design of the OPENSTEP Text system I don't
understand: the ownership policy. The Text System Overview (1) says:

"An NSTextStorage object is conceptually the owner of any network of
text-handling objects, no matter how complex. When you release the
NSTextStorage object, it releases its NSLayoutManagers, which release their
NSTextContainers, which in turn release their NSTextViews."

IMHO the reverse should be true. Shouldn't each view retain and release its
model? The text storage would then be deallocated when nobody is looking. I
believe that the storage shouln't "know" about views (as in a traditional
model-view-controller pattern) and that the implemented policy goes against
the semantics associated with retain/release. Any comments?

Note that there is also a simpler ownership policy, used when an NSTextView
creates the whole network of text objects. In that case :

"Since the NSTextView created these supporting objects, it's responsible for
releasing them when they are no longer needed. When you're done with the
NSTextView, release it and it takes care of releasing the other objects of
the text-handling system. Note that this ownership policy is only in effect
if you let NSTextView create the components of the text-handling system."

(1)
/NextLibrary/Documentation/NextDev/TasksAndConcepts/ProgrammingTopics/TextOverview.rtfd

Marco Scheurer
Sen:te

OPENSTEP/Rhapsody and WebObjects development and mentoring
Mike Ferris
1998-03-17 04:29:17 UTC
Permalink
On the topic of the direction of ownership of the components of the text
system, I think you have a valid argument. There's definitely something
to be said for not having your model "own" your controller and view
layers.

But in the case of the text system, having tried it both ways, I can say
that in the common usage patterns the current direction of ownership
results in simpler code. Alas, as you point out, it does result in the
super-simple case being, pretty much, an inversion of that
directionality. Personally, I regard that inversion as a bit of a wart,
but I don't really think it was the wrong choice.

In general, though, I can't agree with you that having the view own the
whole system is the right way to go either. In my opinion, it often
works out best if the controller layer owns the model and view layers.

Take an example like a graphics program. Say you have model objects
that are Graphics, which are part of a Document. There is a window that
can display the Graphics in a Document which is controlled by a
WindowController. You want the ability to have multiple
WindowControllers (and windows) display the same document (at different
zoom factors or whatever). You want the document to be able to exist
without UI, in case you were just asked to print it or because it is
being used by a script, not a user.

In this case, in my opinion, the Document (controller) would own the
Graphics (model). The Document would own the WindowControllers
(controller) which in turn would own their windows (view). Who owns the
Document is sort of up for grabs, but you might just consider it
self-owned (aka a free-range object). It's the one that has the best
notion of when it is no longer needed (when its last WindowController
closes or somebody specifically tells it close, for instance).

Anyway, I'm not sure there's one right answer here. A pattern needs to
be somewhat flexible. The important thing is to consider the actual
problem and figure out what would work best.

Mike Ferris
Marco Scheurer
1998-03-17 07:57:46 UTC
Permalink
Mike,

I totally agree with you that controllers rather than views should "own" the
system. I was referring to the view owning the model, because with OPENSTEP,
and the Text system, a great deal of the original Smalltalk "controller"
responsibilities are implemented in NSResponder, of which NSView and
NSTextView are subclasses, and there is no Controller in the documented text
architecture.

I'm sure that you had reasons to do it the other way, and you say simplicity
was a factor. Could you be more specific, share your findings? I'm all for
flexibility and engineering trade-offs and against dogmas, but I find this
one disturbing.

Marco Scheurer
Sen:te
OPENSTEP/Rhapsody and WebObjects development and mentoring

Mike Ferris
1998-03-13 20:39:25 UTC
Permalink
Bear with me as I get a little long winded about the text system and how
to edit the text...

There are many ways to modify the text in a yellow text system. There
are user action type methods in NSTextView, such as insertText:,
changeFont:, alignLeft:, etc... which are more or less directly invoked
by actions the user can perform in the user interface. There are also
methods on NSTextStorage which directly modify the backing store.

When to use which API is usually fairly simple to figure out.
Generally, you should use the NSTextView methods if the change is a
direct result of some action the user has taken, and you should use the
NSTextStorage API for other cases. When you use the action-like API in
NSTextView, all the appropriate notifications and delegations for user
text editing are sent. When you use the NSTextStorage API, the
NSTextView notifications and delegations are not sent.

There are also some methods on NSTextView which allow subclasses (or
categories) to implement new user actions correctly. The methods
-shouldChangeTextInRange:replacementString: and -didChangeText let you
easily ensure that all the right notifications and delegations are
sent. Note that you should use these methods only when implementing new
user actions that modify the backing store directly. All the existing
user action methods do this already. So, for example, you don't want to
call -didChangeText after calling -insertText: because -insertText:
already did that for you. (Also, you shouldn't call the NSTextStorage
methods -beginEditing and -endEditing when using NSTextView API to make
changes.) Other methods useful for implementing user actions are the
methods that return the ranges that various types of operation should
act one such as -rangeForUserTextChange or
-rangeForUserParagraphAttributeChange. These range methods return
ranges that are based on the selection range, but are modified if
necessary for the type of change (for example, the paragraph attribute
change method returns the selection range extended to paragraph
boundaries.)

For non-user initiated edits, you use NSTextStorage. NSTextStorage's
-beginEditing and -endEditing allow you to batch up changes. If you do
a -beginEditing, the rest of the text system won't hear about any
changes you make until you do an -endEditing. These are not required,
but if you plan on making more than one consecutive change, you should
consider using these as it helps performance.

Here is the code that you can use to append text to a text system:

[[myTextView textStorage]
replaceCharactersInRange:NSMakeRange([[myTextView textStorage] length],
0) withString:@"Hi there."];

If you want the text laid out and displayed and made visible immediately
(instead of in the background when the text system gets around to it),
you can do something like:

[myTextView scrollRangeToVisible:NSMakeRange([[myTextView textStorage]
length], 0)];

The above code is good for programmatic changes. For an example of how
to write a new user action, see the Text System Overview documentation
or take a peek at the TextExtras source code which you can find at
www.codefab.com/users/mferris.

In general, I heartily recommend reading the Overview documentation and
the spec sheets for at least NSTextView and NSTextStorage if you're
going to be using the text system in any but the most superficial ways.

Mike Ferris
Art Isbell
1998-03-13 21:46:11 UTC
Permalink
Post by Mike Ferris
Bear with me as I get a little long winded about the text system and
how
to edit the text...


Always good reading and appreciated...
Post by Mike Ferris
[[myTextView textStorage]
replaceCharactersInRange:NSMakeRange([[myTextView textStorage]
length],
If you want the text laid out and displayed and made visible
immediately
(instead of in the background when the text system gets
Post by Mike Ferris
around to it),
[myTextView scrollRangeToVisible:NSMakeRange([[myTextView
textStorage]
length], 0)];


Does this apply to attributes changes as well? I change the
text color attribute in
textView:willChangeSelectionFromCharacterRange:toCharacterRange: and
the color change appears immediately without sending
scrollRangeToVisible: (well, the text that is visible changes color
immediately anyway :-)


I continue to have difficulty knowing whether programmatic
changes to visible objects of all classes will automatically be
displayed, whether I have to display explicitly, whether I have to
mark as needing to be displayed, whether I have to ping the window
server, etc. OPENSTEP (and undoubtedly YB) seems improved relative to
NEXTSTEP in this regard, but I'm having a particularly bad time with
NSComboBox and NSBrowser in this regard.

<nofill>
Art Isbell NeXT/MIME: ***@lava.net
IDX Systems Corporation Voice/Fax: +1 808 394 0511
(for whom I don't speak) Voice Mail: +1 808 394 0495
Healthcare Info Technology US Mail: Honolulu, HI 96825-2638</nofill>
Art Isbell
1998-03-16 20:19:05 UTC
Permalink
We had over 600 nibs, most containing DataViews palette text
objects, that we converted from NS/DBKit to OS/EOF2. All of them
failed to save data to a Sybase database correctly because the
default setting for DataViews palette text objects is "Multiple
Fonts" but EOModeler generated a model with NSString attributes for
the text contents of these DataViews palette text objects because the
Sybase datatype was "text", not "binary" or "image", neither of which
is really appropriate for ASCII text. Non-EOF tools must access our
customers' databases, so storing ASCII text as NSData objects is
unacceptable.
So I had to unset multiple fonts in the DataViews palette text
objects in most of the 600+ nibs, a huge chore! That configuration
change then caused run-time errors caused by my sending DataViews
palette text objects methods defined in NSTextView but not inherited
from NSText. I then discovered that unsetting multiple fonts changed
the class of the text object from NSTextView to NSCStringText! Makes
sense, but many programmers don't seem aware of this and may not have
been bitten yet because the default DataViews palette text object
setting results in NSTextView objects. But it will probably happen
eventually, so Apple needs to do more to really explain what's
happening here to avoid confusion later.
</nofill>

Apparently my comments about IB DataViews palette text objects
being NSCStringText objects when multiple fonts are unset applies only
to nibs converted from NEXTSTEP to OPENSTEP (and then to YB, I
suppose). The NEXTSTEP->OPENSTEP conversion process doesn't (can't)
replace the old Text objects with NSTextView objects so NSCStringText
is the OPENSTEP Text compatibility class. I need to manually replace
every text object with one from the OPENSTEP or YB DataViews palette
to rid myself of NSCStringText problems :-(


So this problem won't affect nibs created under OPENSTEP or YB
for which all text objects will the NSTextView objects.


Sorry for any confusion I may have caused!
Continue reading on narkive:
Loading...