Consider this scenario.  You have an NSTextView scrolled to the end and as new text appears in the window, you want to see the new text immediately, so it scrolls to the very bottom for you.  Now you decide you want to read some text further up, so you scroll the text upwards.  As you’re reading, new text gets appended and suddenly it all scrolls down to the bottom again, causing you to lose your place.

We’re going to assume the NSTextView is named textView.  Imaginative, I know.

Usually we could append some coloured text and scroll to the end with something like this…

- (void)writeText:(NSString *)text
{
	// append some blue text
	NSDictionary *attribs = [NSDictionary dictionaryWithObject:[NSColor blueColor] forKey:NSForegroundColorAttributeName];
	NSAttributedString *stringToAppend = [[NSAttributedString alloc] initWithString:text attributes:attribs];
	[[textView textStorage] appendAttributedString:stringToAppend];
	[stringToAppend release];

	// scroll to the end
	NSRange range = NSMakeRange ([[textView string] length], 0);
	[textView scrollRangeToVisible: range];
}

Assuming you’ve just dropped the NSTextView on to a window or view from Interface Builder, the NSTextView will have been placed inside of an NSScrollView.  That NSScrollView can be queried to determine if the scrollbar was already at the bottom.  You should do this before you append any text.

	bool scrollToEnd = YES;

	id scrollView = (NSScrollView *)textView.superview.superview;
	if ([scrollView isKindOfClass:[NSScrollView class]]) {
		if ([scrollView hasVerticalScroller]) {
			if (textView.frame.size.height > [scrollView frame].size.height) {
				if (1.0f != [scrollView verticalScroller].floatValue)
					scrollToEnd = NO;
			}
		}
	}

Firstly we default scrollToEnd to YES. Next we check the NSTextView’s superview’s superview to make sure it is actually an NSScrollView. If it is, and if it has a vertical scrollbar and our NSTextView is large enough to require scrolling, then we look at how far the scroll bar has moved. This can be done by looking at its floatValue.

The floatValue can range from 0.0 to 1.0. If a scrollbar is at the very bottom (or all the way over to the right if it’s horizontal) then it’s floatValue will be 1.0.

Here’s the complete code.

- (void)writeText:(NSString *)text
{
	// determine if we should scroll to the end
	bool scrollToEnd = YES;

	id scrollView = (NSScrollView *)textView.superview.superview;
	if ([scrollView isKindOfClass:[NSScrollView class]]) {
		if ([scrollView hasVerticalScroller]) {
			if (textView.frame.size.height > [scrollView frame].size.height) {
				if (1.0f != [scrollView verticalScroller].floatValue)
					scrollToEnd = NO;
			}
		}
	}

	// append some coloured text
	NSDictionary *attribs = [NSDictionary dictionaryWithObject:[NSColor blueColor] forKey:NSForegroundColorAttributeName];
	NSAttributedString *stringToAppend = [[NSAttributedString alloc] initWithString:text attributes:attribs];
	[[textView textStorage] appendAttributedString:stringToAppend];
	[stringToAppend release];

	if (scrollToEnd) {
		// scroll to the end
		NSRange range = NSMakeRange ([[textView string] length], 0);
		[textView scrollRangeToVisible: range];
	}
}

Tue Aug 25 21:52:15 unknown SpringBoard[23] : Memory level is urgent (9%) and there are no background apps to ask to exit.
Tue Aug 25 21:53:18 unknown SpringBoard[23] : Application ‘MyGame’ exited abnormally with signal 11: Segmentation fault
Tue Aug 25 21:53:19 unknown ReportCrash[4565] : Saved crashreport to /Library/Logs/CrashReporter/LowMemory-2009-08-25-215318.plist using uid: 0 gid: 0, synthetic_euid: 0 egid: 0

As I was a complete noob to the engine, I assumed I’d done something wrong.  I checked my scripts and made sure I wasn’t allocating memory anywhere and that I wasn’t doing anything silly like executing scripts within a loop.  Eventually I ran out of ideas and reverted to iTGB 1.1, which didn’t suffer from the memory leak.

I decided I’d rather use the latest and greatest offering so I thought I’d revisit iTGB 1.2. I recompiled TGEGame with PUAP_OPTIMIZE and PUAP_SCRIPT_CHANGE so the options set are now

__MACOSX__
TORQUE_DISABLE_MEMORY_MANAGER
TORQUE_PLAYER
TORQUE_RELEASE
PUAP_SCRIPT_CHANGE
PUAP_OPTIMIZE
USE_COMPONENTS

I *may* have added the ‘R’ on to the end of TORQUE_DISABLE_MEMORY_MANAGER. There was a typo in some of the projects. Mostly on release configs but I can’t remember which ones.

Then I opened the Xcode_iPhone project and switched to the iTGB_Script_Optimize target. In release build I made sure these were set:

__IPHONE__
TORQUE_DISABLE_MEMORY_MANAGER
TORQUE_PLAYER
TORQUE_RELEASE
PUAP_SCRIPT_CHANGE
PUAP_OPTIMIZE
USE_COMPONENTS

I’m pretty sure I added the ‘R’ on the end of TORQUE_DISABLE_MEMORY_MANAGER this time.

Then I made sure Compiler Version was set to GCC 4.0 and under Linking I changed C++ Standard Library Type from Static to Dynamic.

I also set my iPhone OS Deployment Target and Base SDK to iPhone OS 3.0. You probably don’t need to do that but I’m mentioning it anyway. If you’re having trouble compiling for 3.01 even though you have the latest non-beta iPhone SDK then you may need to create a symbolic link from your Terminal / shell.

cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport
ln -s 3.0 3.0.1

I don’t have the big memory leak any more