On Wed, Mar 19, 2008 at 02:19:09PM -0400, Richard Heck wrote: > That was kind of what I had in mind at one point, and it may be that this > is the best solution in the longer term: To have a Tabular basically be a > matrix of InsetTableCell objects rather than of CellData objects, each of > which embeds an InsetText. But I absolutely do not understand the Tabular > code well enough to even want to try to do this. And the current problem we > face doesn't, I think, require it. > > In fact, I'm now thinking---see my other message---that there's actually an > easy way to do this: Create an InsetTableCell that is a pretty trivial > subclass of InsetText but that contains a reference back to the CellData, > and use it where we're now using the InsetText; it'll also have its own > code, solving a different problem, and it will override forceEmptyLayout() > and the like, but otherwise just pass everything to InsetText. CellData > already has the copy and assignment constructors needed to make this work, > I believe; we just need to reset the reference to CellData in these cases.
But if there's a 1:1 correspondence between such a cell inset and such data it could as well contain the data. Andre'
