I've stumbled across a geometry bug that I can't squash from my end. I wrote a test app to illustrate the issue.
Basically, this is a single-cell IGFlowLayoutView that, after resizing, slides an overlay on top. The overlay is mostly transparent with one subview, a yellow strip at the bottom. Everything works great in portrait orientation (iPad). However, when in landscape (iPad), when the view's height is greater than the width, the overlay's bottom doesn't line up.
Also good...
Broken...
Download the test app here.
Hi Caylan,
I was able to locate the bug from the sample you provided and have fixed the issue. The fix will be released with the next SR. In the meantime, a workaround would be to use the IGOverlayView delegate methods to control where the overlay enters and exits.
- (CGRect)customEnterFrameForOverlay:(IGOverlayView *)overlayView { CGRect result = self.bounds; //Slide up from the bottom into view result.origin.y += result.size.height; return result; } - (CGRect)customExitFrameForOverlay:(IGOverlayView *)overlayView { CGRect result = self.bounds; //Slide down out of view result.origin.y += result.size.height; return result; } - (CGRect)displayLocationForOverlayView:(IGOverlayView *)overlayView { return self.bounds; }
For the following IGOverlayView delegate methods to be called use the IGOverlayAnimationCustomSlide enumeration with the dismiss: and showInView:withAnimation: methods.
Thanks for the quick reply. For some reason, customExitFrameForOverlay and customEnterFrameForOverlay are not being called. I am getting a call for displayLocationForOverlayView... just not the custom frame delegates. Any ideas?
Torrey said: For the following IGOverlayView delegate methods to be called use the IGOverlayAnimationCustomSlide enumeration with the dismiss: and showInView:withAnimation:methods.
For the following IGOverlayView delegate methods to be called use the IGOverlayAnimationCustomSlide enumeration with the dismiss: and showInView:withAnimation:methods.
Did you catch the last line of my previous reply?
Hehehe, nope. ;)
I have logged this behavior in our internal issue tracking system with ID 174388 and I have opened a private case for you (CAS-139267-P4T7Y9), so that you can be notified as soon as the fix is released. You can view this case at https://es.infragistics.com/my-account/support-activity.
Instead of making the overlay full-view, another option is to make the overlay the exact size it needs to be, and position it accordingly. This fixed the issue...
- (CGRect)displayLocationForOverlayView:(IGOverlayView *)overlayView
{
CGRect viewBounds = self.view.bounds;
if(viewBounds.size.height > viewBounds.size.width)
viewBounds = CGRectMake(0, viewBounds.size.height - SemiNotificationViewDefaultHeight, viewBounds.size.width, SemiNotificationViewDefaultHeight);
}
return viewBounds;
Ok, I have the delegates running but making those changes did not affect the landscape orientation when height>width. Still the same weird layout... Are you sure you saw the fix in landscape? It's easy to think it's fixed but you're still in portrait. I confirmed the delegate methods were operating as expected by creating a 0-0-100-100 rect for the displayLocation. I thought i could get smart and test for portrait and height>width and then flip them (because that's what it looks like is happening), but it seems like there is some Infragistics Framework layout code that's tweaking and applying some kind of strange logic (max/min?).