Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Yes, they have meaning in tabulars (the only multi-text insets we have),
inset -> tabular
idx -> tabular cell
pit -> paragraph inside this cell
pos -> position inside the paragraph
OK but I don't think this is a valid use of pit and pos in this case.
One should use:
idx -> tabular cell
getText(idx).pit -> paragraph inside this cell
getText(idx).pos -> position inside the paragraph
using pit and pos as shortcuts is wrong IMHO.
I must confess I don't understand what are you talking about. What shorcuts?
There should be another CursorSlice inside the cell pointing to the
InsetText isn't it?
inset -> InsetText
pit -> paragraph inside this text
pos -> position inside the paragraph
If the CursorSlice points to an InsetTabular (i.e. inset -> tabular),
pit and pos have no signification at all. Unless of course you assume
that a cell is mandatorily an InsetText (which it is in our case). In
this case pos and pit are really the pos and pit of the inner InsetText.
That's why I call them shortcut.
Is that clearer? It is also possible that I don't understand this stuff
as well as I think :-(
My four items where the ones stored in a cursorslice pointing to some
position inside a tabular.
It seems that there's no convenient way to iterate over all cells of a
tabular with a DocIterator :-/ The assert in forwardIdx is correct
considering that the past-the-end idx doesn't lead to a valid cursor
position.
This situation will happen anytime we use fordwardIdx() in a loop so I
modified nevertheless the assertion to fix the crash:
Maybe the best would be to move the method to CursorSlice where it belongs,
there you don't have the constraint of keeping a valid cursor position...
In DocIterator now it's misleading because it's the only forward* method
that travels into an invalid cursor position...
good idea.
Abdel.
