Display NSStream Output
Display NSStream Output
- Subject: Display NSStream Output
- From: Adam <email@hidden>
- Date: Tue, 22 Feb 2005 11:41:08 -0500
My app is a client connected to a server. It has its own socket class
that is based on NSStream. Whenever the server has data available the
run loop calls NSStreamEventHasBytesAvailable. I parse this data line
by line and output it with NSLog(); A simple case statement causes all
kinds of things in my app to happen. No problems. However, the problem
I am running into is if I want to display the raw data to the user of
the app in a NSTextView.
In high volume times 10+ lines a second can came across. The GUI of my
app lags and there is nothing I have been able to do to stop it. I have
tried putting the text directly into the textStorage I have tried
replaceCharactersInRange:withString: I tried writing the data out to a
text file and then reading it back into the NSTextView.
Do you have any advice on how to print this data to the user without it
lagging my GUI? Do I need a separate thread?
This is what I am currently doing, but I have tried much simpler and
more complex ideas,.
[[consoleChatMainTextView textStorage] setFont:[NSFont
systemFontOfSize:9]];
[[consoleChatMainTextView textStorage] setForegroundColor:[NSColor
redColor]];
NSMutableString *consoleString = [NSMutableString string];
[consoleString appendFormat:@"%@ \n", aMessage];
NSRange r = NSMakeRange([[consoleChatMainTextView string] length], 0);
[consoleChatMainTextView replaceCharactersInRange:r
withString:consoleString];
[consoleChatMainTextView
scrollRangeToVisible:NSMakeRange([[consoleChatMainTextView string]
length], [[consoleChatMainTextView string] length])];
On Feb 22, 2005, at 2:03 AM, Chris Campbell wrote:
On Feb 22, 2005, at 01:00, Adam wrote:
Looks like some people have gone to some strange lengths to make it
work. I think this will work, but oye vey, talk about convoluted. Can
you see an alternative?
I could give you the design philosophies behind why text fields and
steppers don't work like you're expecting, but suffice to say...that's
just not how Cocoa works. Whenever something is done to a control
*programatically*, it doesn't trigger an action method, or affect the
text editing at all (text editing is done solely by the user typing in
the field).
When you call setStringValue: on a field, it doesn't call the action
method. That seems intuitive, yes?
When you call setIntValue: on a field, it works just like
setStringValue:, but the field first converts the int into a string
and then displays it.
When you connect a stepper to a text field and tell it to send
takeIntValueFrom:, it's sending a message to the field whenever it's
clicked. So the text field doesn't see the user doing this -- it sees
something happening programmatically: it's being sent a message to
change it's value. That doesn't trigger an action method.
Steppers and text fields and buttons, etc, are the V (View) in M-V-C
design. 90% of your work when creating an app is writing the C
(Controller) part. In MVC design, the View communicates user actions
to the Controller. Sure, Interface Builder will let you have the View
communicate to other parts of the View (that's what control-dragging
from a slider to a text view is doing), but that's not usually how
your programs should be designed.
As far as a nib fib with 600 connections...anything with 600 anythings
in it is horrible programming, and needs to be broken up into more
manageable pieces. If I have more than 1 window in a nib file, it
makes me cringe and redesign my code. The ability to use multiple nibs
in a single program isn't a feature for the computer -- it's a feature
for the programmer, so we can wrap our heads around the complex
systems we design.
Good luck!
- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden