This question already has answers here:
Accordion table cell - How to dynamically expand/contract uitableviewcell?
(5 answers)
Closed 6 years ago.
I am trying to recreate the collapsable date picker that the calendar app uses when creating a new event. I've put an example of what I'm trying to do on github
In short, I've created a static table, added three cells. The first cell is for the date, and contains a button to toggle the second cell. The second cell is the date picker. The third cell is arbitrary. In the code I'm trying to set the height of the table cell (and the date picker if needed) to zero, and then toggle the size whenever the user clicks the button. No matter what I've tried, I can't a) get the cell to collapse without some sort of gap, and 2) get the animation to smoothly transition from expanded to collapsed and back again.
Edit: This question is not the same as the duplicate answer, in that I wanted to expand a separate table cell and not the same cell as being selected. But, I personally can live with using a same-cell expansion. I also updated my github project so future people can see a working example.
It's very simple; you are probably over-thinking things here. This functionality is built in; Apple wants you to be able to expand and contract a cell. You just aren't using the API Apple has provided. Use it! Here's how.
The date picker cells are always present. But their height is zero (and their clipsToBounds is true) so you don't see them. So implement heightForRowAtIndexPath to return zero for those cells.
To show a date picker cell, change what heightForRowAtIndexPath returns (this is easiest if you have a property that holds this value, so you can just change the property value and have heightForRowAtIndexPath read it from there) and say:
self.tableView.beginUpdates()
self.tableView.endUpdates()
That's all there is to it!
Here's a quick demo I made. The red and orange things are cells. The table has three cells but the second one, containing the date picker, starts out with zero height:
Related
I'm having a hard time figuring out how to individually style a cell or group of cells when a certain thing happens. For instance I would like to be able to right-click on a cell and hit something like "tag" and it would change the background color of the cell to something different. I would like to do the same thing with rows, columns, or any random group of selected cells. I also need this change in style to persist even if the cell(s) are moved beyond the viewport layer's view.
If you have a hard time with NatTable, maybe it is worth reading some of our tutorials and documents.
https://www.eclipse.org/nattable/documentation.php?page=styling
http://www.vogella.com/tutorials/NatTable/article.html
In short related to your question. Individual styling is done via config labels on a cell and styles that are registered in the ConfigRegistry for that label. So what you need to do is to implement some sort of label registry based on cell indeces. That label registry then needs to be used by a custom ConfigLabelAccumulator so the labels are attached to the cells with the corresponding indeces.
We have a basic implementation on a column base via the ColumnStyleEditorDialog. This can be seen in the _000_Styled_grid example by clicking on the column header and call "Format cells". Personally I think that feature is not complete, but it should help you in seeing how it works in principle.
It took me forever to figure out how to set up editing on a custom cell view for an NSTableView. Thanks to StackOverflow I figured that much out. P.S. I was doing all of this in Interface Builder.
I have a single column table in which the cell is a custom multi-control NSTableCellView, with:
name (in bold)
description
detail
It's all text. Set up editability on the name only. The table is sorted by the name.
When I edit the name, it has the effect on the bound model that I expect. The table even re-sorts correctly. However, it's displaying incorrectly. The description and detail (not editable) still show up correctly, but the name (which was edited) is a blank. When I inspect the model, it has the correct updated value. But the cell view itself is incorrect.
This doesn't happen all the time--it typically happens if the cell is re-sorted to the top or bottom of the table, but that may be a red herring and may instead have to do with NSTableView cell caching or something.
I hacked up a workaround in which I assign a delegate to the NSTextField (automatically generated for the NSTableCellView) and intercept the textShouldEndEditing event. For some reason this event is getting triggered twice for a given edit (after I press "enter" in the text field)--once for the actual edit where fieldEditor.string is different from the model name, followed by another event where fieldEditor.string is the same as the model name. If I return false for my textShouldEndEditing handler in the latter case, then the cell contents end up being drawn correctly. That's the hack.
I feel like I'm doing something wrong here though, and that shouldn't be necessary.
Is the textShouldEndEditing event supposed to be fired twice?
I just inherited code which hides/shows rows a UITableView by using the delegate heightForRowAtIndexPath method and returning height 0 for "hidden rows".
The code works, but it has me concerned there might be fraught with unforeseen complications. Can someone either ease my concerns or give me good reasons why this could cause problems (I couldn't find any issues with initial testing).
The table is fairly small <10 rows total and would require custom row heights even without this hidden row solution.
I do the same thing in the code I just worked on. I am not happy with different behaviour for different table view settings.
The alternative in my case is more complex (a model that adapts to what is visible or not).
For now, I put a //HACK comment on it and document a few peculiarities.
This is what I have found (iOS 5.0 tested):
Set tableView.rowHeight = 1; Zero will give a cell with zero height (as returned by tableView:tableView heightForRowAtIndexPath:) some default height.
You must have a cell separator. If none is selected, then a default height is assigned to zero height rows. The height of 1 is included with the separator.
If your code works in a different way, it would be interesting to know how it is set up.
It would be cleaner to add and remove the rows between two beginUpdates and endUpdates calls, but I don't see why this 0-height method should not work.
If there are no UI-artifacts, that is (e.g. the Delete button showing up overflowing to the next cell).
I use this method of setting hidden cell heights to 0. It works well and also means I can animate the inclusion of new cells by expanding the cell height (such as adding a DatePicker Cell like the calendar app does).
A few things I have had to watch out for in iOS 7.1 are that very squashed text does still appear even when a cell height is = 0 so I've needed to remove cell text in that case. Also, I have change the size of the cell's separatorInset as that was appearing as well.
I am beginner iphone developer I want created table in programatically. In the table we take more than 20 row. But i have some problem that after 11th row the same value repeated.
plz help me with code and other method
You may want to look at this question which is the same problem. In that case, the person was setting the text of the cell only when creating a new cell (when nil was returned from [tableView dequeueReusableCellWithIdentifier:].) It needs to be set every time the tableView:cellForRowAtIndexPath: is called.
when you use reuseIdentifyer, the new cell to display is the cell that has just disappeared. so it will contain all the data from the disappeared cell. for example, if the cell, that has just disappeared, has detailDisclosureIndicator, the new cell will have it too even you don't set it.
I have a UITableView with some empty sections. I'd like the user to be able to move a row into them using the standard edit mode controls. The only way I can do it so far is to have a dummy row in my "empty" sections and try to hide it by using tableView:heightForRowAtIndexPath: to give the dummy row a height of zero. This seems to leave it as a 1-pixel row. I can probably hide this by making a special type of cell that's just filled with [UIColor groupTableViewBackgroundColor], but is there a better way?
This is all in the grouped mode of UITableView.
UPDATE: Looks like moving rows into empty sections is possible without any tricks, but the "sensitivity" is bad enough that you DO need tricks in order to make it usable for general users (who won't be patient enough to slowly hover the row around the empty section until things click).
I found that in iOS 4.3, the dummy row needs to have a height of at least 1 pixel in order to give the desired effect of allowing a row to be moved into that section.
I also found that the dummy row is only needed in the first and last section; any sections in between don't have this problem.
And it looks like in iOS 5.0, no dummy rows or special tricks are needed at all.
While managing the edit, you can monitor if the table view is in Edit Mode. Use that flag inside of cellForRowAtIndexPath to decide weather or not to display the 'blank' row. While in 'regular' mode, the row will not display, but when the user taps 'edit' cellForRowAtIndexPath should get called again and this time decide to display the row. The details of how to do that depend on your data source and how you are gluing it to the display. If you aren't getting the call again, you can manually inject rows with insertRowsAtIndexPaths / deleteRowsAtIndexPaths and/or call reloadData to force a refresh.
I found that if you return -1.0 from the heightForRowAtIndexPath method it will remove the 1 pixel line.