I had a text view and i was taking chat that came in from the internet and was printing it but i wanted more colors than a textview had to format the chat.
I replaced the textview with a scrollview and in viewdidload i attempted ( seemed to work) to attach my view class to it.
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
_myconsoleview = [[ConsoleView alloc] initWithFrame:[self._scview bounds]];
[_myconsoleview setBackgroundColor: [UIColor yellowColor]];
[self._scview addSubview:_myconsoleview];
[self._scview setNeedsDisplay];
}
well as text got to the bottom it didn't scroll ( i tried dragging the text are with the mouse and looked for scroll bars).
so this example core text program says oh thats easy to get scrolling. just make my custom view (ConsoleView) inherit the scroll view itself. So i try this and add this now:
#interface ConsoleView :UIScrollView<UIScrollViewDelegate>
still no scrolling. no scroll bars. no indication and i'm using the ipad simulator so far, of any kind of scrolling. In ConsoleView i want to do something very polished eventually but for now i'm just printing a single string. But the string gets longer as i get more text as i'm appending to it.
i tried this in my sendtext method. this hits when they hit a button to send the text they type in this textfield to the server:
[myconsoleviewid addNewText:newText];
[_scview scrollRectToVisible:[_scview bounds] animated: TRUE];
[_scview setNeedsDisplay];
I honestly am not sure i can claim the above would work but i figured something might work. any ideas? I'm fairly new to ios programming having started about 2 months ago and worked on it off and on so far. In java or android there doesn't seem to be much more to getting like a console to scroll than to add it to some scroll control. But IOS is proving trickier.
Mike
edit. this is my draw rectangle which is suppose to print the string which gets longer and longer. its in consoleview:
- (void)drawRect:(CGRect)rect
{
[super drawRect:rect];
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetTextMatrix(context, CGAffineTransformIdentity);
CGContextTranslateCTM(context, 0, self.bounds.size.height);
CGContextScaleCTM(context, 1.0, -1.0); CGMutablePathRef path = CGPathCreateMutable(); //1
CGPathAddRect(path, NULL, self.bounds );
CTFramesetterRef framesetter =
CTFramesetterCreateWithAttributedString((__bridge CFAttributedStringRef)attString); //3
CTFrameRef frame =
CTFramesetterCreateFrame(framesetter,
CFRangeMake(0, [attString length]), path, NULL);
CTFrameDraw(frame, context); //4
CFRelease(frame); //5
CFRelease(path);
CFRelease(framesetter);
}
The ScrollView's contentSize must be larger than the ScrollView's frame in order to allow scrolling. Set this property correctly and you should be fine.
You need to set scrollView.contentSize with proper size of scrollable area.
scrollView.contentSize = CGSizeMake(640, 320); // if you are in full screen and have two view one to other in horizontal
// for vertical scrolling you need to do
scrollView.contentSize = CGSizeMake(320, 640);
This examples are only for one way scrolling horizontal or vertical if you set the contentSize bigger than view frame size if will be scrollable.
Related
What I Want to Do:
In Messages.app on OS 10.10, when you scroll the left-most pane (the list of conversations) upwards, a nice horizontal line fades in over about 0.5 seconds. When you scroll back down, the line fades back out.
What I Have:
I am trying to achieve this effect in my own app and I've gotten very close. I subclassed NSScrollView and have done the following:
- (void) awakeFromNib
{
_topBorderLayer = [[CALayer alloc] init];
CGColorRef bgColor = CGColorCreateGenericGray(0.8, 1.0f);
_topBorderLayer.backgroundColor = bgColor;
CGColorRelease(bgColor);
_topBorderLayer.frame = CGRectMake(0.0f, 0.0f, self.bounds.size.width, 1.0f);
_topBorderLayer.autoresizingMask = kCALayerWidthSizable;
_topBorderLayer.zPosition = 1000000000;
_fadeInAnimation = [[CABasicAnimation animationWithKeyPath:#"opacity"] retain];
_fadeInAnimation.duration = 0.6f;
_fadeInAnimation.fromValue = #0;
_fadeInAnimation.toValue = #1;
_fadeInAnimation.removedOnCompletion = YES;
_fadeInAnimation.fillMode = kCAFillModeBoth;
[self.layer insertSublayer:_topBorderLayer atIndex:0];
}
- (void) layoutSublayersOfLayer:(CALayer *)layer
{
NSPoint origin = [self.contentView documentVisibleRect].origin;
// 10 is a fudge factor for blank space above first row's actual content
if (origin.y > 10)
{
if (!_topBorderIsShowing)
{
_topBorderIsShowing = YES;
[_topBorderLayer addAnimation:_fadeInAnimation forKey:nil];
_topBorderLayer.opacity = 1.0f;
}
}
else
{
if (!_topBorderIsShowing)
{
_topBorderIsShowing = NO;
// Fade out animation here; omitted for brevity
}
}
}
The Problem
The "border" sublayer that I add is not drawing over top of all other content in the ScrollView, so that we end up with this:
The frames around the image, textfield and checkbox in this row of my outlineView are "overdrawing" my border layer.
What Causes This
I THINK this is because the scrollView is contained inside an NSVisualEffectView that has Vibrancy enabled. The reason I think this is that if I change the color of my "border" sublayer to 100% black, this issue disappears. Likewise, if I turn on "Reduce Transparency" in OS X's System Preferences > Accessibility, the issue disappears.
I think the Vibrancy compositing is taking my grey border sublayer and the layers that represent each of those components in the outlineView row and mucking up the colors.
So... how do I stop that for a single layer? I've tried all sorts of things to overcome this. I feel like I'm 99% of the way to a solid implementation, but can't fix this last issue. Can anyone help?
NB:
I am aware that it's dangerous to muck directly with layers in a layer-backed environment. Apple's docs make it clear that we can't change certain properties of a view's layer if we're using layer-backing. However: adding and removing sublayers (as I am) is not a prohibited action.
Update:
This answer, while it works, causes problems if you're using AutoLayout. You'll start to get warnings that the scrollView still needs update after calling Layout because something dirtied the layout in the middle of updating. I have not been able to find a workaround for that, yet.
Original solution:
Easiest way to fix the problem is just to inset the contentView by the height of the border sublayer with this:
- (void) tile
{
id contentView = [self contentView];
[super tile];
[contentView setFrame:NSInsetRect([contentView frame], 0.0, 1.0)];
}
Should have thought of it hours ago. Works great. I'll leave the question for anyone who might be looking to implement these nice fading-borders.
I am looking to alter an existing iOS application so that instead of using multi-touch gestures to size and rotate images (two-finger pinch/zoom and twist), I want there to be a handle on all four corners of the image and one at the top so that the user can grab one of the handles to re-size or rotate.
I have been researching the topic but am unable to find anything pointing me in the right direction.
See this image for an example of what I'm talking about-
I'm assuming that because you're starting with a app that already has working pinch-zoom and twist gestures that your question is merely how to show those translucent circles for the handles. I'd be inclined to create UIView subclass that draws the circle, like so:
#implementation HandleView
- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
self.backgroundColor = [UIColor clearColor];
self.userInteractionEnabled = YES;
}
return self;
}
- (void)drawRect:(CGRect)rect
{
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextAddEllipseInRect(context, rect);
CGContextSetFillColorWithColor(context, [[UIColor colorWithWhite:1.0 alpha:0.5] CGColor]); // white translucent
CGContextSetStrokeColorWithColor(context, [[UIColor colorWithWhite:0.25 alpha:0.5] CGColor]); // dark gray translucent
CGContextSetLineWidth(context, 1.0);
CGContextDrawPath(context, kCGPathEOFillStroke); // draw both fill and stroke
}
#end
You could achieve the same effect with CAShapeLayer layers, too, if you didn't want to write your own drawRect with Core Graphics calls like I did above. But the idea would be the same.
Your view controller can then add those five views and add gesture recognizers for them, like so:
HandleView *handleView = [[HandleView alloc] initWithFrame:CGRectMake(50, 50, 50, 50)];
[self.view addSubview:handleView];
UIPanGestureRecognizer *pan = [[UIPanGestureRecognizer alloc] initWithTarget:self action:#selector(handlePan:)];
[handleView addGestureRecognizer:pan];
Just repeat that for each of the handles you want on the screen. and then write your gesture recognizer to do whatever you want (e.g. move the bounding rectangle, move the appropriate handles, etc.).
Sounds fairly straight forward. The view hierarchy of one possible solution as ASCII art:
Container (ScalingRotatingView)
|
+----imageView (UIImageView)
|
+----upperLeftScalingHandle (HandleView)
|
+----upperRightScalingHandle (HandleView)
|
+----lowerLeftScalingHandle (HandleView)
|
+----lowerRightScalingHandle (HandleView)
|
+----rotatingHandle (HandleView)
All instances of HandleView would have a pan gesture recognizer, that feeds one of two methods in your controller:
--updateForScaleGesture:, where you’d use the gesture recognizer’s -translationInView: to compute and store the new scale, before updating the frames of all views appropriately, and resetting the translation to 0, and
- -updateForRotationGesture:, where you’d use the gesture recognizer’s -translationInView: to compute and store the new angle before updating the frames and resetting the recognizer’s translation.
For both calculations you need the translation in the coordinate system of the image view. For the scaling part, you can then simply divide the new edge lengths by the natural image dimensions, for the rotation you can use the approximation that only the x component of the translation matters:
sin(x) = x (for small values of x)
Oh, and it sure helps if the anchor point of your image view sits at its center…
I have a UITextView, which sets its text dynamically from an RSS feed. The textview is a subview of a UIScrollview. Ultimately, I am creating a mobile newspaper app, so the user should be able to scroll through the text (and other subviews).
After creating the views in IB, I added
NSString *sourceCode = [NSString stringWithContentsOfURL:[NSURL URLWithString:self.URL] encoding:NSUTF8StringEncoding error:&error];
sourceCode = [self parseHTMLText:sourceCode];
CGSize maximumLabelSize = CGSizeMake(320,9999);
CGSize txtStringSize = [sourceCode sizeWithFont:self.body.font
constrainedToSize:maximumLabelSize];
CGRect newlblFrame = CGRectMake(0, 0, 320, txtStringSize.height);
self.body.frame = newlblFrame; //body is the textview
self.body.text = sourceCode;
self.scroll.contentSize=CGSizeMake(320, self.body.frame.size.height+300); //scroll is scrollview
A typical NSLog will display body frame = {{0, 0}, {320, 2088}} scrollview frame = {{0, 0}, {320, 417}} scrollview content size = {320, 2388}
However, when I run the app, body maintains its interface builder height of around 196 and the scrollview won't scroll (when i move it, it just bounces back to its original position)
On a side note, when I try to manually change the frame of the textview with CGRectMake, the NSLog shows the correct height, but the view doesn't appear different. I made sure that it's hooked up correctly in IB, because I can adjust other properties, like background color.
EDIT:
After I set the cliptoBounds property of the textview to NO, the textview now adjusts its height and tries to show the entire text. However, it cuts off at the end of the screen, and I still cannot scroll.
Here is what I see currently. I made the scrollview background color gray for convenience. I'm not sure why part of the scrollview is partially in white and and partially gray. (Title) is a separate label btw)
I fixed the problem by moving the code from viewDidLoad to viewDidAppear. Apparently this is an Xcode 4.5 specific issue, resulting from the AutoLayout feature overriding the logic in the viewDidLoad method. A better explanation can be found here.
i hope this will help you
self.scrollview.contentSize=CGSizeMake(320, label.frame.size.height+30);
Try to add this :
[_scrollView setClipsToBounds:YES];
Try this:
CGSize maximumSize = CGSizeMake(200.0, 30.0); // Specify your size. It was for my screen.
UIFont *txtFont = <Ur Font size & Var>;
//new
//fontValue = txtFont;
//new
lblValue.font = txtFont;
lblValue.lineBreakMode = UILineBreakModeWordWrap;
CGSize txtStringSize = [commentTxt sizeWithFont:txtFont
constrainedToSize:maximumSize
lineBreakMode:lblValue.lineBreakMode];
CGRect newlblFrame = CGRectMake(105.0, y, 200.0, txtStringSize.height);
lblValue.frame = newlblFrame;
lblValue.text = #"Your String";
After this set scroll Content size. Hope it'll work for you. It worked for me.
Try to solve in the following way.
// adjust the height of UITextView with content height
CGRect frame = self.body.frame;
frame.size.height = self.body.contentSize.height;
self.body.frame = frame;
// adjust UIScrollView's height with the height of UITextView
self.scroll.frame = frame;
I'm looking for a way to draw a fade effect on a table view (and outline view, but I think it will be the same) when the content is scrolled. Here is an example from the Fantastical app:
Also a video of a similar fade on QuickLook windows here.
To make this I tried subclassing the scrollview of a tableview with this code:
#define kFadeEffectHeight 15
#implementation FadingScrollView
- (void)drawRect: (NSRect)dirtyRect
{
[super drawRect: dirtyRect];
NSGradient* g = [[NSGradient alloc] initWithStartingColor: [NSColor blackColor] endingColor: [NSColor clearColor]];
NSRect topRect = self.bounds;
topRect.origin.y = self.bounds.size.height - kFadeEffectHeight;
topRect.size.height = kFadeEffectHeight;
NSRect botRect = self.bounds;
botRect.size.height = kFadeEffectHeight;
[NSGraphicsContext saveGraphicsState];
[[NSGraphicsContext currentContext] setCompositingOperation: NSCompositeDestinationAtop];
// Tried every compositing operation and none worked. Please specify wich one I should use if you do it this way
[g drawInRect: topRect angle: 90];
[g drawInRect: botRect angle: 270];
[NSGraphicsContext restoreGraphicsState];
}
...but this didn't fade anything, probably because this is called before the actual table view is drawn. I have no idea on how to do this :(
By the way, both the tableview and the outlineview I want to have this effect are view-based, and the app is 10.7 only.
In Mac OS X (as your question is tagged), there are several gotchas that make this difficult. This especially true on Lion with elastic scrolling.
I've (just today) put together what I think is a better approach than working on the table or outline views directly: a custom NSScrollView subclass, which keeps two "fade views" tiled in the correct place atop its clip view. JLNFadingScrollView can be configured with the desired fade height and color and is free/open source on Github. Please respect the license and enjoy. :-)
I have two instances of NSScrollView both presenting a view on the same content. The second scroll view however has a scaled down version of the document view presented in the first scroll view. Both width and height can be individually scaled and the original width - height constraints can be lost, but this is of no importance.
I have the synchronised scrolling working, even taking into account that the second scroll view needs to align its scrolling behaviour based on the scaling. There's one little snag I've been pulling my hairs out over:
As both views happily scroll along the smaller view needs to slowly catch up with the larger view, so that they both "arrive" at the end of their document at the same time. Right now this is not happening and the result is that the smaller view is at "end-of-document" before the larger view.
The code for synchronised scrolling is based on the example found in Apple's documentation titled "Synchronizing Scroll Views". I have adapted the synchronizedViewContentBoundsDidChange: to the following code:
- (void) synchronizedViewContentBoundsDidChange: (NSNotification *) notification {
// get the changed content view from the notification
NSClipView *changedContentView = [notification object];
// get the origin of the NSClipView of the scroll view that
// we're watching
NSPoint changedBoundsOrigin = [changedContentView documentVisibleRect].origin;;
// get our current origin
NSPoint curOffset = [[self contentView] bounds].origin;
NSPoint newOffset = curOffset;
// scrolling is synchronized in the horizontal plane
// so only modify the x component of the offset
// "scale" variable will correct for difference in size between views
NSSize ownSize = [[self documentView] frame].size;
NSSize otherSize = [[[self synchronizedScrollView] documentView] frame].size;
float scale = otherSize.width / ownSize.width;
newOffset.x = floor(changedBoundsOrigin.x / scale);
// if our synced position is different from our current
// position, reposition our content view
if (!NSEqualPoints(curOffset, changedBoundsOrigin)) {
// note that a scroll view watching this one will
// get notified here
[[self contentView] scrollToPoint:newOffset];
// we have to tell the NSScrollView to update its
// scrollers
[self reflectScrolledClipView:[self contentView]];
}
}
How would I need to change that code so that the required effect (both scroll bars arriving at an end of document) is achieved?
EDIT: Some clarification as it was confusing when I read it back myself: The smaller view needs to slow down when scrolling the first view reaches the end. This would probably mean re-evaluating that scaling factor... but how?
EDIT 2: I changed the method based on Alex's suggestion:
NSScroller *myScroll = [self horizontalScroller];
NSScroller *otherScroll = [[self synchronizedScrollView] horizontalScroller];
//[otherScroll setFloatValue: [myScroll floatValue]];
NSLog(#"My scroller value: %f", [myScroll floatValue]);
NSLog(#"Other scroller value: %f", [otherScroll floatValue]);
// Get the changed content view from the notification.
NSClipView *changedContentView = [notification object];
// Get the origin of the NSClipView of the scroll view that we're watching.
NSPoint changedBoundsOrigin = [changedContentView documentVisibleRect].origin;;
// Get our current origin.
NSPoint curOffset = [[self contentView] bounds].origin;
NSPoint newOffset = curOffset;
// Scrolling is synchronized in the horizontal plane so only modify the x component of the offset.
NSSize ownSize = [[self documentView] frame].size;
newOffset.x = floor(ownSize.width * [otherScroll floatValue]);
// If our synced position is different from our current position, reposition our content view.
if (!NSEqualPoints(curOffset, changedBoundsOrigin)) {
// Note that a scroll view watching this one will get notified here.
[[self contentView] scrollToPoint: newOffset];
// We have to tell the NSScrollView to update its scrollers.
[self reflectScrolledClipView:[self contentView]];
}
Using this method the smaller view is "overtaken" by the larger view when both scrollers reach a value of 0.7, which is not good. The larger view then scrolls past its end of document.
I think you might be approaching this in the wrong way. I think you should be getting a percentage of how far down each scroll be is scrolled in relation to itself and apply that to the other view. One example of how this could be done is this way using NSScroller's -floatValue:
NSScroller *myScroll = [self verticalScroller];
NSScroller *otherScroll = [otherScrollView verticalScroller];
[myScroll setFloatValue:otherScroll.floatValue];
I finally figured it out. The answer from Alex was a good hint but not the full solution as just setting the float value of a scroller doesn't do anything. That value needs translation to specific coordinates to which the scroll view needs to scroll its contents.
However, due to differences in size of the scrolled document view, you cannot just simply use this value, as the scaled down view will be overtaken by the "normal" view at some point. This will cause the normal view to scroll past its end of document.
The second part of the solution was to make the normal sized view wait with scrolling until the scaled down view has scrolled its own width.
The code:
// Scrolling is synchronized in the horizontal plane so only modify the x component of the offset.
NSSize ownSize = [[self documentView] frame].size;
newOffset.x = MAX(floor(ownSize.width * [otherScroll floatValue] - [self frame].size.width),0);
The waiting is achieved by subtracting the width of the scroll view from the width times the value of the scroller. When the scaled down version is still traversing its first scroll view width of pixels, this calculation will result in a negative offset. Using MAX will prevent strange effects and the original view will quietly wait until the value turns positive and then start its own scrolling. This solution also works when the user resizes the app window.