Hi Stephen, 

(1) No, there are no invisible views, however, I am using your tab view that slides on and off screen and can be repositioned on any side of the screen.  You can see the light blue tab of the collapsed slide tab view in the video.

(2) the grid height varies on what data is being displayed.  In cases where the grid extends beyond the bottom of the screen, the row that's present at the bottom when tapped will no respond to taps, but if you scroll it upwards away from the bottom of the screen, it does become tappable.  

(3) The "city" cell is the bottommost row in the grid.  When I pull up on the grid to expose the white area below the "city" cell, that is just the view I'm placing the gridview on.

Regarding the nil'ness of the cell, all the cells are produced through the same cellAt: method, and whether there is data or not, merely depends on what was read from my data structure into the cell.textLabel.text 

In all cases, I am producing a cell and placing it in the gridview.

Would the view that the grid is placed on be considered "invisible" per your first question?

I'm assuming not, because you probably mean views that sit in FRONT of the grid view, not behind it.

Thanks

Dave.

Hi Dave, 

So based on what you said in your response for (2) "the row that's present at the bottom when tapped will no respond to taps, but if you scroll it upwards away from the bottom of the screen, it does become tappable."

That leads me to believe that the parent container the grid is in is not as big as the grid. 

So basically you're seeing the full grid, b/c the parent isn't clipping its children, however, anything outside of the parent's bound won't be interact-able. 

One easy way to test this out is by tell the grid's parent to clip it's bounds. 

Something like: 

 yourGridView.superview.clipsToBounds = YES;

-SteveZ

Steve, 

I ran the app and then applied Reveal to it, and there is something that looks interesting.

Can you take a look at the next video I uploaded to same location.

This one is titled "Infragistics Tap Handler Issue"

Thanks a lot

Dave.

Hey Dave, 

Thats not an issue, the CellsContainerView is allowed to be bigger, as the GridView is just a scrollView, meaning that the CellsContainer will be the total size of all of the content of the grid. 

From what i saw and what you described though, something is definitely clipping or blocking the bottom of the grid. 

I would first try making the height of the grid smaller than it's parent, just to eliminate the grid being the issue. 

Then assuming that was fine, i would walk up the parent tree. In the video you just sent, you just showed the immediate parent, but the issue could be caused by any parent up the tree. 

-SteveZ

Stephen, 

I haven't quite gone far enough to prove it yet, but I'm REALLY suspicious of the slide tab control.

I added an extra bogus row at the end of my IGGridView so that I could scroll up further.

I colored it black, so that's the black strip you see below the yellow box.

Notice in this screen composite I put together, in the first position I show, the yellow box is NOT tappable.

However, if I scroll up just a tiny bit more, as shown in the bottom portion of my composite, the yellow box does become tappable, and presents the popover. 

Reveal shows nothing else in front of the IGGridView in the Z-order, other than the slide tab view.

Hi Torrey, 

No, I don't have anything in gridView:willSelectCellAtPath: that could potentially return nil and prevent the cell from being selected.  

I am going to play with your project and see if I can get it closer to what I'm doing because technically my app works a little differently.   I don't have the gridview taking up the whole screen as a content view, rather the grid comes and goes as a portion of the screen to show data based on what icons a user taps on.

Also, I don't use a grid datasource helper.  I have my own data and the grid gets built using the cellAt: method.

Hopefully by building up your example, I can discover what's causing the problem.

I'll keep you posted on my progress, and reupload a modified version if I run into the issue but can't diagnose it.

Hi Torrey, 

I've been using the SlideTabView for about 9+ months now and it hasn't caused any issues I'm aware of until this unique scenario.   I made a video showing the SlidTabView control in my app, and rotated it in Reveal so you can see how things line up and what's what.  You can also see that order that controls are overlapping.  The IGGridView is overlapped by the tab on the IGSlideTabView.  I did try sliding the tab over to the left (not in the video), so it's not directly over the gridview, but that didn't make the cell tappable either.

As best I can tell, a row's cells won't become tappable until the bottom of the row is around 15 pixels above the bottom edge of the screen.  Any closer and the cell doesn't respond to taps.

I put the video in the folder I linked to in my initial post above, and titled it "Slide Tab Control"

I also added a pic of the code that I'm using.  The code to build / show / hide is all there.

Take a look and see if it looks correct, or if you notice anything odd.

Hi Dave,

Steve is off today and I wanted to jump in and learn how you've used the IGSlideTabView to determine if there's an issue. We had a case in the past where a user wasn't adding views to the slide tab's contentAreaView which in turn caused interaction issues. The IGSlideTabView is meant to be used like a container and views should be added to the contentAreaView. This is to help manage padding and view placement.

Does your implementation follow this pattern? If you need a quick sample demonstrating usage, I'd be happy to make one for you.