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

rootView some times problem in this place of logic. #57

Closed
Samback opened this issue Dec 30, 2013 · 4 comments
Closed

rootView some times problem in this place of logic. #57

Samback opened this issue Dec 30, 2013 · 4 comments

Comments

@Samback
Copy link

Samback commented Dec 30, 2013

Probably it will be great not only check for if(!view.isHidden) because when I use hud it's the first element :) Maybe it will be better to check for [view isKindOfClass:UIViewController] ?

  • (UIView *)rootView
    {
    UIWindow *result = [[UIApplication sharedApplication] keyWindow];

    if (result.subviews.count > 0)
    {
    for (UIView *view in result.subviews)
    {
    if(!view.isHidden)
    {
    return view;
    }
    }
    // result = [result.subviews lastObject];
    }

    return result;
    }

@hsoi
Copy link
Contributor

hsoi commented Jan 24, 2014

I just got bit by -rootView as well, but in a different way.

I looked at the closed issues here and I see #46 and #47 are related, and explain why the -isHidden check is in there.

But I'm curious as to why this -rootView method is in there in the first place. Why isn't keyWindow itself sufficient? What is -rootView trying to accomplish? What assumptions is it making, and could it be stronger and more directly explicit about what it's seeking? @nicolaschengdev you obviously have your reasons for doing what you did and why you did it, and knowing that would be useful in understanding all of this and coming up with a more solid solution (given the current implementation seems to be causing issues for a number of people).

In my case, I am using a debugging tool called DCIntrospect-ARC. It inserts a view, DCTextView into the window subviews, and it winds up being the view that -rootView finds and returns. This of course causes WYPopoverController to fail.

I can work around my own special case there (and depending how all this goes, I can submit the workaround in a pull request). But I'd rather see if there's a more solid solution to be had on this issue.

Thanx @nicolaschengdev for both the class itself (so far it seems like the best popover replacement out there these days), and for your consideration on this matter.

hsoi added a commit to barz/WYPopoverController that referenced this issue Jan 24, 2014
I see on github there have been issues with this -rootView method, similiar to what I encountered. There’s an open issue on this, and I added my voice to it, regarding my particular case:

nicolaschengdev#57
@nicolaschengdev
Copy link
Owner

Hi,

a more solid solution is to add popover on top of subviews. In the same window of the view which is passed as argument in the following method :

- (void)presentPopoverFromRect:(CGRect)rect
                        inView:(UIView *)view
      permittedArrowDirections:(WYPopoverArrowDirection)arrowDirections
                      animated:(BOOL)animated
                       options:(WYPopoverAnimationOptions)options;

I am currently working in order to implement this solution. And to support orientation and keyboard with this solution.

nicolaschengdev added a commit that referenced this issue Jan 30, 2014
@hsoi
Copy link
Contributor

hsoi commented Jan 30, 2014

Cool. I will look at this in the coming days and let you know how it goes. Thank you!

@hsoi
Copy link
Contributor

hsoi commented Feb 3, 2014

Finally got a chance to try this out. So far so good! Seems like a better solution all around. Thanx.

orta pushed a commit to orta/WYPopoverController that referenced this issue Apr 27, 2015
Modified code that deals with repositioning popover on orientation change
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

3 participants