Cool, thanks for the superfast response.

I'll take a look at it after a meeting.

Dave

Hey Dave, 

So, i simplified your code a bit and add some extra logic for you. 

It looks like you'll want to transpose your data. And with just a little tweak to the DataSourceHelper, you can do that, without having to change your data. 

So i created a custom DSH for you, and i grouped it by a property on the data object called row, so that it will repeat automatically. 

Then i hooked into the delegate, so that when you tap on a data cell, it will show an alert. In that method, you can see how you can resolve the actual value clicked through the DSH. 

Hope this helps, 

-SteveZ

We're making an app that's similar to the picture below.

The fields and data are fake, but representative of what we're doing.

We're working on an iOS version of an app that's going to mimic a .NET app for the PC desktop.

For the iOS version, to reduce input errors, and validation requirements, we are going to use a lot of combo box style lookups (pickers for iOS), and of course date pickers for dates, etc.

The usage scenario is that a user would tap on a cell in the 2nd column of the gridview, and then the code would determine whether the tapped cell is allowed to be edited, and if so, based on the datatype, a popover would display containing a date picker, combo box, or whatever as needed to enter the data quickly and accurately.  For numerical value fields, I'd display a numeric keyboard (I think iOS already provides that option, but I need to figure it out).

So if I were to use popovers for all the 2nd column cells that were editable (as not all of them would be), could I then disable all columns for editing and use my popovers to enter the data, thereby getting around the double-tap gesture?

I know how to make and display popovers, but any grid view code you want to provide in this regard would of course be helpful.

Thanks

Dave.

Hi David, 

Welcome to the iOS world! I actually came from a .Net background myself. In fact i've written a few blog posts about transitioning form C# to Obj-c. Perhaps it could help you get up to speed a bit quicker: 

http://es.infragistics.com/community/blogs/stevez/archive/2013/05/09/c-to-objective-c-the-ultimate-guide.aspx

There are also a bunch of post about general tips on working on the platform: 

http://es.infragistics.com/community/blogs/stevez/default.aspx

In terms of providing your own editing, you can basically do whatever you'd like with the IGGridView. Its extremely flexible. The IGGridViewDataSourceHelper, is actually just an object that implements the IGGridViewDataSource protocol. This is why editing is enabled through the DSH, and not the IGGridView. Using the DSH has a lot of advantages, and one of them is that you can create custom IGGridViewColumnDefintion objects or you can even specify your own custom cell. So if you want a specific column to always have an editor displayed, you can do exactly that. 

If you have an idea of how you want it to work, i can probably whip you up a sample to get you started. 

-SteveZ

Ahhh, the double-tap gesture... yep, that's it.

You can verify that in the project I gave ya.

I actually have the first column disabled for edits (because those are the field names).

It's the second column that's enabled for editing.

It would be great if there was a way to remove the double-tap gesture... or perhaps to disable the column for editing, but then edit anyway through another means, like providing my own editor or something.  If you have any ideas along these lines, let me know.

Regarding "Btw, i noticed that you're re-declaring the delegate and datasource methods in the internal interface of your class. You know you don't need to do that right?"

Heh, you'd be shocked at how much I don't know.

Just writing a line of code can take hours sometimes.

I've been a .NET programmer for the last decade and was recently forced into iOS programming through no fault of my own.

While I have been interested in learning it, it's a massive wall to climb.  XCode, iOS, LLDB, Objective-C, Cocoa Touch, third party libraries... 

Hopefully I'll scale it in the next few years.  

That's the nature of the work though.  I'd still rather do this than just about anything else.