I'm trying to add spaces in between rows in an NSTableView, like how it looks here.
Currently, however, my rows look like this, with 0 spacing between them.
Is it possible to add these spaces? I found this post on how to do it, but that's for UITableView, and I don't think you can add sections with NSTableView. Another thing I tried was using intercellSpacing on the table view, like so:
tableView.intercellSpacing = NSSize(width: 0, height: 80)
However, that just increases the height of each row rather than increase the space between them.
Lastly, I looked into drawSeparator, which seems promising but has limited documentation. Would extending NSTableRowView and overriding the drawSeparator method work, basically by drawing in a blank space as the separator? If so, how would I go about making my table view use my custom row view class?
If none of these options work, I'd also be open to faking the effect, maybe by having the actual content of a row be smaller than the row itself and using the remaining space as the padding between rows. However, I'm not sure if this would work, given that right now I'm using NSShadow, which highlights the boundary of each row.
Found a way to work around this issue. Before, each row consisted of two columns, one for the text fields and one for the buttons. However, I've changed it by putting all the text fields and buttons into a single column, that way there's only one cell per row. I then can apply the NSShadow and other styles to the NSTableCellView rather than the NSTableRowView. This means that I can now use intercellSpacing to create vertical spacing between cells:
tableView.intercellSpacing = NSSize(width: 0, height: 80)
The rows are still touching, but I've disabled the borders/highlighting on them so you can't actually see them. The cells, on the other hand, are visible, and you can adjust the spacing/styles on them as necessary.
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.
I think this is more of a general issue. I would like to use a textfield that gets dynamic data and doesn't stretch more than a given max height. For instance, I have a textfield that, if it gets text that fits in one line, the textfield will be one line height, and i have other elements under it, that will move up with float positioning. Or, if I want a 3 line max height and if the text exceeds that space, then the rest will be trimmed.
I don't want to use java expressions to trim that text, as it is not always accurate. I am new to jasper and I am trying to know if there is any way to do this. I did a lot of searches, but maybe there is something that i missed, and i hope someone can help me. Thank you
I managed to solve this by extending net.sf.jasperreports.engine.fill.TextMeasurer and overriding initialize() method; also I had to extend net.sf.jasperreports.engine.util.AbstractTextMeasurerFactory and override the createMeasurer() method.
Now, whenever I want to have max # of lines, with no overflow, I add a property to that text field (e.g. maxLines) which is being passed to my custom TextMeasurerFactory. I hope this helped you.
We had a similar problem at work with JASPER Reports 4.5, where we had an invoice with a header and a table. We wanted the header to have dynamic height based on the lengths of certain fields (like address, partner name, etc,), but not more than a critical limit, otherwise the header will push the table and thus making a mess by splitting it across multiple pages. Also, the invoice shouldn't exceed 1 page.
We eventually had to move the header in the background section, where we also put a background for the table consisting of vertical lines (so it will extend to the end of an A4 page) and a white opaque square.
This way, if the header exceeds the max height it will go underneath the table's background, cropping the text. This was the desired effect we were looking for.
Sounds crazy, but it worked ...
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'd like to add section headers to my grouped table view's sections but I'd like them to appear seamless (see image). The default, as we're all well aware of, is rounded top corners on the first row of a grouped table view cell so it ends up looking like crap when you merge them.
Any way to specify when indexPath.row = 0 that the UITableViewCell should use row style "middle" or something like that?
If not then what are my options? I guess I could scratch the section header and use Row 0 as a quasi-header then push my array data +1 to fill the rest of the table? I'd rather not roll my own from scratch...if possible.
Sample Table http://img35.imageshack.us/img35/8181/sampletable.png
Edit:
"Crap" looks like this:
alt text http://img25.imageshack.us/img25/9748/crapsection.png
Don't do what you're doing, it's against HIG
Ok, ok, I'll tell you how to do it:
You're going to want to do your own cell background views. The default grouped one is not what you want.
When a tableview asks you for a cell, set its backgroundView and selectedBackgroundView to something that looks appropriate for its place in the tableview.
Usually, this means a UIImageView with the appropriate image, though you can go wild here with a custom view, but there are gotchas.
So in your case, you would do
if (indexPath.row > sectionRowCount - 1) {
//Not the last row
//Put in the middle background
} else {
//Put in the end background
}
Then you'll want a custom table section header, but that's pretty easy.
In your case, you probably won't have to worry about when there's just one row, so that makes things even easier.
Take a look at the tutorial here:
cocoa with love basically what you need is 3 different images. One for the top row, one for the bottom, and a 3rd for the middle rows.
You could also not use the section header, but instead use a custom cell as the first cell of the section. So when ([indexPath row] == 0), return a custom cell that is the "header" and then return the "regular" cells (offset by one row) for the rest. You'll also have to make adjustments to the numberOfRowsInSection function to return +1.
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.