Hi Roberto,
Your conjecture is exactly right. If you have visible space in your table below the last row, and you ask the table how many visible rows it has, the table takes the extra white space and divides it by the default, explicit size of a hypothetical row (which is 25). You're right. It might very well be the case that when you actually create those extra rows, they won't be sized to 25 pixels each. Their size might depend on the font height, but this font height can change from cell to cell -- the row sizes itself to the maximum height of all the cells in the row. It might even the case that one particular cell, in a given row, might report more than one line of text (see ATTR_MIN_NUM_LINES_VISIBLE), which will cause the row to increase its height. So there's really no reliable way to calculate what the true row height of a future row will actually be. Therefore, the table uses 25 as a not-very-insightful default.
The gist of this is that the ATTR_NUM_VISIBLE_ROWS isn't very meaningful when the table is bigger than the actual cell grid (and conversely for ATTR_NUM_VISIBLE_COLUMNS vis-a-vis the actual number of columns).
Now consider the case where you do have more rows beyond the visible area of the table. In this case, a partially visible row is still considered to be "visible". This is why if your table extends below a given row, even if it's just by one pixel, then the number of visible rows increases by one (since we can't return a fractional number). It doesn't matter whether only 1 pixel of the last row is visible, or almost all pixels are visible. That row is still considered to be "visible" (even if, practically speaking, it isn't).
In conclusion, if you want to set the table to an exact number of rows, you should set the ATTR_NUM_VISIBLE_ROWS attribute, rather than ATTR_HEIGHT, and you should do this only after you've actually created the rows.
Luis
