Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

topView may be hidden #20

Open
hiworld75018 opened this issue Jan 26, 2013 · 4 comments
Open

topView may be hidden #20

hiworld75018 opened this issue Jan 26, 2013 · 4 comments

Comments

@hiworld75018
Copy link

The topView in showAtPoint:inView:withContentView: may lead to a hidden view.

Maybe this works better ?

NSArray* windowViews = [[[UIApplication sharedApplication] keyWindow] subviews];
for (int i = windowViews.count - 1; i >= 0 ; i--)
{
topView = [windowViews objectAtIndex:i];
if (!topView.isHidden)
break;
}

@jallen
Copy link

jallen commented Jan 31, 2013

I've had the same problem.
My question is do we need a topView?
Why not just use the parentView? (What am I missing?)

@ocrickard
Copy link
Contributor

In response to @jallen, I built this component so I could present a popover from a UIView subclass with clipping enabled. I'm now tempted to just add a new UIWindow to the top of the window stack.

As for checking for the hidden state of topView, I think this solution reveals an underlying problem: I had assumed that the topView would be adequate, but it is clearly not. We could continue looking for hidden or clipped subviews, but what if their layer's zPosition is set below others such that the popover is not visible?

I'll think on this, and look at more general solutions.

@devios1
Copy link

devios1 commented Jan 9, 2015

I have to agree with @jallen. Using the immediate superview (or some customizable ancestor) makes a lot more sense. I am using popovers inside a scrollView that I am using to display text field validation warnings. In this case I naturally want the popovers to scroll with the text fields, but by using the topView (or a new UIWindow as you suggest), the popover is outside of the scrollView and remains static on the screen while the underlying view is scrolled, forcing me to hide the validation messages if/when the scrollView is scrolled.

Instead, to solve your problem of the popover being attached to a view with clipping enabled, would it not make more sense for the target view to be overridable? This is a pattern I am employing in my app: if you don't specify the target view, it defaults to self.superview. This lets you specify any parent view (or even a completely different window if so desired) without losing the ability for the popover to be directly attached to the immediate superview and thus contained inside any scrollViews, etc.

I made the following simple changes and things seem to be working great. I probably broke something else, but for my use this is working perfectly (the popover views now scroll appropriately with the views they are attached to):

PopoverView.m
Line 483: topView = view;
Line 525: topViewBounds = topView.frame;

That's all it took, and it works great now. You can still specify what view you want the popover to appear in, and that simply becomes the topView now. No need to actually attach the view to the top-most view.

@wasauce
Copy link
Contributor

wasauce commented Jan 9, 2015

@devios1337 If you have a pull request we can investigate if there are conflicts and potentially merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants