I have 4 UIView (each has a visible part on the screen) and I want them to be draggable.
I am adding them just like any other view on a controller with
addSubview:dragViewTop
addSubview:dragViewBottom
addSubview:dragViewRight
addSubview:dragViewLeft
My problem is that if I drag one view on top of another, even if I change it's layer.zPosition, I am able to drag one that is supposed to be beneath.
That behavior is given (I think, not sure) by the order of the added views.
I want that the view I am dragging stays on top. Any ideas?
I hope I made myself clear.
You need to work with the superview of those views to deal with the order of the views, not their layers' zPosition property.
Use the following methods of the superview to arrange the depth of the subviews. It seems you probably need only the first method, though.
- (void)bringSubviewToFront(UIView *)view
- (void)sendSubviewToBack(UIView *)view
- (void)exchangeSubviewAtIndex:(NSInteger)index1 withSubviewAtIndex:(NSInteger)index2
To bring view to top:
[view.superview bringSubviewToFront:view];
(note: this is the front of the subviews of view.superview so views that are in front of the superview will stay in front)
Related
I have a UIViewController that I designed in Interface Builder. near the top of the View it has a UIImageView and then some other Views (Text etc) below. These are set to anchor to the top of the view.
In code when the view loads I remove the UIImageView in certain circumstances but it still seems to take space or the view's below don't spring up to the top based on their Anchor.
How can I make the Views below move up if the View above is removed?
You can change the frame of the other elements in the view.
in the viewDidLoad method you can use something like that:
-(void)viewDidLoad{
if(imageVisible){
otherElements.frame = CGRectMake(....);
}else{
otherElements.frame = CGRectMake(....);
}
}
I don't know what is the structure of the view, but you might consider nesting all of the other elements in one view so you could change all the elements positions in one command.
Unlike the Android view hierarchies, iOS view hierarchies are all developed in absolute coordinates. When you say a subview is anchored to the top, that means that if the size of the parent view changes, your view will stay in the same relative position to the top of the screen.
In order to make your views below the image view move up when the image is hidden or removed, you will have to manually arrange them yourself to account for the offset
I am having trouble understanding how layering is performed within Xcode. I have a .xib with a view, that view has 6 UIImageView 's which each contain a different image. I have created IBOutlets for each of these so I can change the image at runtime.
I now want to change the order the UIImageViews are drawn at runtime, so imageA at the back is now drawn on top of everything else. How can I change the layer order? I originally tried removing all the subviews and using [self.view insertSubview: atIndex: ] to see if I could change the draw order that way but my code crashes.
Can anyone tell me the correct method for doing this please?
Thanks in advanced,
Elliott
i guess you are looking for these UIView methods:
1:
exchangeSubviewAtIndex:withSubviewAtIndex:
Exchanges the subviews at the specified indices.
- (void)exchangeSubviewAtIndex:(NSInteger)index1 withSubviewAtIndex:(NSInteger)index2
2:
bringSubviewToFront:
Moves the specified subview so that it appears on top of its siblings.
- (void)bringSubviewToFront:(UIView *)view
3:
sendSubviewToBack:
Moves the specified subview so that it appears behind its siblings.
- (void)sendSubviewToBack:(UIView *)view
with these methods you can exchange the subviews order to get one UIView appear over one other in their superview... if that's what you were asking....
A crash may be because when you remove the image from its parent, its retain count goes to zero and is deallocated.
If you just want to swap two views, see - (void)exchangeSubviewAtIndex:(NSInteger)index1 withSubviewAtIndex:(NSInteger)index2 on UIView. If you want to do a more complicated exchange, you can remove and readd, just make sure you retain the view you remove (ARC notwithstanding).
This is more of a check as I believe this is right but its a lot of work if I'm wrong.
I want to basically achieve fixed positioning with a scrollView. I want to have a list along the top that is always visible, scrolls horizontal only and then a scrollview beneath that to move around the information which scrolls both vertically and horizontally.
I figure I need to subclass UIScrollView and overwrite touchesBegan, touchesMoved and touchesEnded to send the touch to both UIScrollViews.
Is this right or off track?
Cheers
Overriding the touch events on a scroll view is probably not what you want to do. Instead you can simply use a single scroll view, and then in the parent view's -layoutSubviews or in the scroll view's delegate methods you can move the list so it's always at the same vertical position (use the scroll view's contentOffset property to determine where that should be). Both the delegate method and -layoutSubviews is called before the drawing actually occurs after the scroll view scrolls, so by always repositioning your view where you want it to be, it will appear to remain fixed to the user.
I have a UIView which contains a zoomable UIImageView and also another semitransparent UIView on top of that.
What I am trying to achieve is to be able to zoom the UIImageView while keeping the semitransparent view static and not zoomed.
If I add the semitransparent UIView on top of the UIImageView (which is added to the UIScrollView), everything zooms. However, if I add both as subviews to the base UIView, the touches only get tracked is the semitransparent UIView since its the last one added.
I do need control to reside first at the semitransparent UIView for the touches since I may want to resize the semitransparent view. However, I'd like to pass control of the touches to the UIScrollView if two fingers are used. Is there anyway for me to achieve this? The nextresponder doesn't seem to work. I also tried to use hittest in addition to subclassing UIWindow, but the base UIView needs to push/pop navigation controlling ability so I don't think I can subclass UIWindow to push onto the navigation stack.
Any help would be appreciated.
Thanks,
Winston
Hm.. you can try this hierarchy (possibly subclasses):
UIView (container)
> UIView (semitransparent overlay)
> UIScrollview
- UIView (zoomable content)
Like this, the overlay does not scale.
The tricky thing then is the user interaction on multiple layers. Its easy if there are areas in your overlay that should not detect user touches, for that you just set the UIView property 'userInteractionEnabled' to 'NO' for the view parts where touches should be 'forwarded' to the underlaying layers.
But if I get you right, you need something more complicated. You probably could set up some kind of master-touch-controller in the container UIView, that finds out what is happening and then calls certain methods of its subviews / forwards the events.
I don't know all the exact methods you need to override/implement in the container, but check out the tapZoom demo from the ScrollView Suite sample code. It's a pretty nice example there.
Just out of curiosity, may I ask what this interaction model is used for?
I have a UITableViewController inside of a UINavigationController.
I want to have a UIView appear over the top of the table view but not susceptible to the scrolling of the table view.
I.e. if the table view is scrolled, the UIView should remain in the same position relative to the screen, rather than relative to the table view. It should appear anchored in a certain position.
What is the best way to achieve this?
EDIT: To clarify, the view should float transparently over the top of the table view.
Many thanks!
I also wanted to have a floating UIView over my tableView.
So, within my RootViewController (which is a UITableViewController), this worked for me
- (void)viewDidLoad {
/* mylabel is a UILabel set in this class */
[self.mylabel setUserInteractionEnabled:NO];
/* navigationController comes from higher up in the navigation chain */
[self.navigationController.view addSubview:self.mylabel];
}
Similar to what Peter said, create a UIView that will contain both the TableView and the subclassed UIView. Such as:
UIView *view = [[UIView alloc] initWithFrame:frame]; // Define frame as you like
[view addSubview:myTableView]; // This is the reference to your tableView
[view addSubview:myAnchoredView]; // This is the reference to your UIView "floating" subclass
You will also need to turn off user interaction for your floating view. I don't know if this will specifically pass the touches to the underlying UIView's or not though:
[myAnchoredView setUserInteractionEnabled:NO];
If this is blocking touches to your tableView, you may need to pass the reference to your tableView to the anchored view at initialization, then pass the touch events along. You can do this by overriding the touch response methods in UIResponder. (If there is a better way, someone please speak up.)
Do you mean the anchored view should appear transparent over the UITableView, or just above, i.e. anchored view uses top 20% of the available space, table view uses the rest?
In any case, create a UIView containing the anchored view and the table view. If you want the anchored view transparent over the table view, it's a bit tricky, because to scroll the table view, touches have to pass through the anchored view.
Add the surrounding view's view controller to the navigation controller instead of just the tableview.
I investigated how UIScrollView keeps its scrollIndicator above the UIScrollView's content and yet unmoving by examining a UIScrollView in the debugger.
The scrollIndicators are UIImageViews. And you can see they are direct descendants of the UIScrollView itself. You can also see that any scrolled content is also a direct descendent. So how is it that the scroll indicators don't move?
I tried updating the position of my static content constantly in - (void)scrollViewDidScroll:(UIScrollView *)scrollView this, surprisingly, works. I'm not sure if it is how UIScrollView itself does it, but without some private magic, it must be something like this.