How to ensure tableView.scrollTo() displays correctly when initializing the table - javafx-8

I am building a screen where the system jumps to rows in a TableView based on error conditions. Not all rows will be touched. My table view can hold approximately 23 rows. When there are less details than that I have no issues.
However when there is more and the first item in error is off the visual flow, I get weird rendering on the first access only.
In this example, I have 63 rows of data, and the first row that needs to be reviewed is like 35.
When the system determines the row it needs to access I jump there by first selecting the row and then scrolling the table to it:
When I initialize the table:
tableView.getSelectionModel().setCellSelectionEnabled(true);
tableView.setItems(sorted);
tableView.setEditable(true);
In the call to select the next row:
int nextRow = determineNextRow();
tableView.getSelectionModel().select(nextRow, columnToEdit);
tableView.scrollTo(nextRow);
At this point the table scrolls off top & bottom. And the display looks like this:
After entering the amount, it drops to the next line and everything looks OK.
I am not quite sure how to correct the initial landing.
Thanks.

Related

Iterating all rows and changing a specific value ends up in a disappearing table

I have following problem: I have a small application running where i have implementes a language switching function. Therefore i need to change the datetime columns in footable for the right date format.
My idea was to iterate through all rows, get the date value, recalculate it in the right format and write it back to the table. But This approach is not working properly, when i try it, you can see the very first row changing, and then the whole table disappears. I have attached some screen shots and the relevant code to explain the problem...
My Code (for iterating the rows and changing the value):
var ft = FooTable.get("#spiele_data");
$.each(ft.rows.all, function(i, row){
v=row.val();
var m = moment(v.sp_timestamp, 'L LT');
v.sp_timestamp=m.format('L LT');
row.val(v);
});
This is what happens:
Table is loaded and displayes properly
After changing the language => see the first line
Immediatley after that the table is gone
What am i doing wrong or is there a better possibility to change specific columns in all rows?
Best regards
Christian
+EDIT: One more thing: the $.each-loop is iterated completely. I've tested that by writing the index to the console.
$('table').trigger('footable_redraw');
You need to call redraw to see footable again

Is there any way to avoid PostgreSQL placing the updated row as the last row?

Well, my problem is that each time that I make an update of a row, this row goes to the last place in the table. It doesn't really matter where was placed before.
I've read in this post Postgresql: row number changes on update that rows in a relational table are not sorted. Then, why when I execute a select * from table; do I always get the same order?
Anyway, I don't want to start a discussion about that, just to know if is there any way to don't let update sentence place the row in the last place.
Edit for more info:
I don't really want to get all results at all. I have programmed 2 buttons in Java, next and previous and, being still a begginer, the only way that I had to get the next or the previous row was to use select * from table limit 1 and adding offset num++ or offset num-- depending of the button clicked. So, when I execute the update, I lose the initial order (insertion order).
Thanks.
You could make some space in your tables for updates. Change the fill factor from the default 100%, no space for updates left on a page, to something less to create space for updates.
From the manual (create table):
fillfactor (integer)
The fillfactor for a table is a percentage
between 10 and 100. 100 (complete packing) is the default. When a
smaller fillfactor is specified, INSERT operations pack table pages
only to the indicated percentage; the remaining space on each page is
reserved for updating rows on that page. This gives UPDATE a chance to
place the updated copy of a row on the same page as the original,
which is more efficient than placing it on a different page. For a
table whose entries are never updated, complete packing is the best
choice, but in heavily updated tables smaller fillfactors are
appropriate. This parameter cannot be set for TOAST tables.
But without an ORDER BY in your query, there is no guarantee that a result set will be sorted the way you expect it to be sorted. No fill factor can change that.

What is the expected semantics of the Sheet data? Should null values be returned?

I have a sheet with 18 columns and 137 rows. Some of the columns are empty. When I make the get sheets call (I'm using the C# SDK) the data returned has the following structure which seems anomalous to me ...
Columns --- 19 (the RowID is tacked on at the end of the list)
Rows --- 137 (good) but when I examine the number of cells in the rows, I get varying numbers: 18, 18, 17, 16, 18. It appears to drop the null-valued cells. Is this intentional to drop null cells? If so, why doesn't it always drop null cells? It's a little strange that the cell count doesn't reflect the column count.
The only way I can figure to work around this is to correlate using the ColumnId since there is no guarantee that there will be exactly 18 cells returned for each row.
It appears to drop the null-valued cells. Is this intentional to drop
null cells?
That is correct cells that have never been touched by the user are not sent via the API. This approach will reduce the payload and is beneficial for clients such as mobile.
If so, why doesn't it always drop null cells?
It will always drop the null cells (cells that have not been touched by the user).
However, there is a case where empty cell data is returned. This will occur when a user adds text in a cell, saves the sheet and then deletes the text. It will now appear that the cell is empty but we still store history for this cell so it is not truly a null cell or untouched cell.
The only way I can figure to work around this is to correlate using
the ColumnId since there is no guarantee that there will be exactly 18
cells returned for each row.
If you need to have the cell match up to an exact column (or column position) then we do recommend using the column id as the key.

Erroneous duplicate rows in BIRT report

I have a problem with a BIRT report I'm working on where I have a nested table in the report. The outer table contains data to do with an item on an invoice, while the inner table contains stuff to do with price banding for labor charges. I've written a separate DataSet which gets the inner data, bound by parameters to data in the outer table. Now, when I preview the inner DataSet in BIRT using the defaults I've given it, it returns two rows of data for that bill number & item number - a normal rate & an overtime rate if you like. When I run the report in full over the same data, the outer table stuff is fine, but the inner table just repeats the same row over twice - it's just the first row repeating.
This is sorta what the table looks like in layout view:
Item Description Rate Quantity Item total
[item] [desc] [rate] [quantity] [total]
...where the price & quantity are in the inner table.
I'd have expected to see something like:
Item Description Rate Quantity Item Total
1 Callout $40 1 $40
2 Labor $30 4.5 $185
$50 1
but instead I get more like:
Item Description Rate Quantity Item Total
1 Callout $40 1 $40
2 Labor $30 4.5 $185
$30 4.5
...even though querying the database & previewing the inner data set based on the same input criteria show the expected result.
Has anyone else had experience like this? I have a hunch it's to do with bindings, but not sure what.
One way to get this behavior is by accidentally replacing a table-level binding with a column-level binding.
For example, define a table by dragging a data set into the report. Select the entire table (use the outline view, or select something in the table and then click on the "Table" button that pops up just below the grid.) Then go to the Binding tab. Note that the data set and column bindings are all filled in.
Now select just one field in the Detail row. On the Binding tab, note that the Data Set is blank, and no column binding is shown. Someone who is confused by this (as I was) might then edit the column's binding and specify the same Data Set that was used to create the table. If you do this you will only see a single value repeated in that column when you run the report. (I believe the overridden column is binding to a second instance of the data set, not the one the table is iterating over.)
Not sure your question can be answered withou looking at the data and the design. But it is important to note that the results you see in the dataset preview, and not neccisarly what you would see if the query was run fully. I have seen difference with 7 records returned. I thought as it was only 7 it would be the same on full run, but it's not. The preview is not just a top 500 query, it has some other (not sure what) filters also.
To problem solve if it is your query or your binding.
If you are using a SQL database. Run the SQL in a SSMS query and see if you get the same results you do when run in the innner table.
Altentively, create a new test report, copy over your dataset and use with a stand alone table.
I think I sorted it, & this is the most bizarre thing: On the child table I'd been deleting the header & footer row & just leaving the detail row in, in the layout view. Last thing today, just before I was going to go home, I tried again - deleted the table for about the 70th time that day, replaced it, re-did the parameter bindings all exactly as before, but this time I left the header row & footer intact. Clicked the preview tab, voila, all shows up correctly. So, since I didn't need the header or footer on the child table, I went into properties, clicked Hide this element, preview again - all good. No difference to the data bindings, no difference to mappings or anything else, no change to the data sets - the only difference was leaving the header & footer in place but hidden.
Contemplating making a bug report, tbh.

Y position while composing a PdfPTable

I'm building a pdfptable thru ItextSharp, but I need to know, while I'm adding cells, my Y position in the page. Cells have a variable height.
I need to know it to avoid tu put a new 'Breaking title' in the table if this would go on the last table row, as it should go on a new page (on cust request).
I tried writer.getverticalPosition() but it seems not reliable in composing a table.
Is there a way to know it ?
There's a contradiction in your question. Let me explain what doesn't make sense.
You create a PdfPTable, let say you have an object named table. when you add cells to table, the object grows. Plenty of data is stored into memory.
Now you say: I want to know the Y position of the rows on the page while I'm adding cells.
Which page? There may not even be a page? As long as you build the table object, there is no page, there are no Y positions. One table could be 200pt heigh when added to a page with a width of 400pt. The same table could be 400pt heigh when added to a page with a width of 200pt. It isn't until you add the table object to a Document that the table gets its shape.
If you want to make sure a "title" isn't the last row on a page, you should break up your table in smaller parts. Create a subtable and add it to the document. Now use getVerticalPosition() and check how much space is left. If there isn't sufficient space for the first X rows of the next subtable, move to a newPage() and add the next table there, otherwise add the table on the current page.
If you define the widths correctly, nobody will see that you've been adding more than one table: it will look as if you added one large table instead of different small ones. If you don't know how to calculate the height of the rows in the subtables, please note that you need to define the total width of the table and lock the widths. For the reason explaiined above, no software can calculate the height of a table if it doesn't have any info about its width.