Table Cut and Paste Resets Some Properties

Running the latest beta on Windows XP, Ubuntu 10.04/Wine, and Ubuntu 10.04/Native, here’s the test case:

  1. In an otherwise empty document, create a two column, two row table.

  2. Fill each cell with appropriate text

  3. Select every cell

  4. Open “Table Properties” dialog

  5. Pull down the “Cell Length” choice list and select “Variable”

  6. Add a line of text below the table to provide context.
    Screenshot-1.png

  7. Select the table; select “Copy”; select “Cut”; move cursor below the text from step 6

  8. Paste the table back. Note that the “Cell Length” property reverts to “Percentage”.

  9. Restore the intended widths and add more text below.
    Screenshot-3.png

  10. And finally, close the project, and open it again. The result resembles Screenshot-2.png, but since the attachment maximum is three (now there’s a stupid rule) I can’t add it. It’s important because not only is the table not restored properly, but the blank line between the additional text and the table has been deleted. I’ll post a followup with the last screenshot.

This is obviously not a killer bug, but obviously there are some object states that aren’t propagating properly. The cell width thing might not be the only one, but it’s the only one I’ve tested at the moment. And since I’m writing something with tables that depend on this property being saved properly… well then.

Cheers,

Nathan

Here’s the last screen shot:

bump

I can confirm this table behavior on Windows XP using 0.0.26. My experience has been that table widths (Percentage or Variable) are not being preserved. Sometimes it reverts while using the software after jumping between other sections, but it will always revert after saving, exiting, and reopening the document.

Hi, I’ve just started using Scrivener and getting my head around. I have had the same problem with my table being reformatted after copying and pasting it from Microsoft Word 2010 (on Windows Explorer Professional). I will attempt to reformat the table as suggested above.

Perhaps more frustratingly, however, after visiting another section of my report I came back to find all of the values (aside from headings) were no longer in the table. Has anyone else encountered this problem? Or is this just a rookie error?

Sorry guys, not ignoring you. I’ve reproduced the table properties issue too (thanks for the excellent instructions) and Lee is aware of it.

This one I haven’t seen. Is the text gone or just not in the table? Is this only with tables you’ve copied and pasted from Word 2010? Had you edited them at all before switching to another document and back? If you have steps to reproduce this, that would be great, as it definitely sounds buggy.

Hi there,
Just to reiterate I am using Microsoft Word 2010 on a computer running Windows XP Professional. It might also be worth noting the file I am using in MW 2010 is a Word 97-2003 Document (*.doc). This is largely because my company has recently changed from MW 2003 to 2010 and has not made *.docx the default.

The process I went through was reasonably straight forward:

  1. Initially I copied all of the text from my word document including a table. (I did this just using normal copy shortcuts: CTRL C).
  2. I pasted the text and table into Scrivener (using CTRL P)
  3. I did not make any changes to the table in Scrivener.
  4. I started working on a different section of my report
  5. When I came back to the previous section where I had pasted the table all of the values (aside from bold headings) were no longer in the table.

I have tried this again with a different table and the same thing happened. All the was remaining was the bold headings.

Just to check it was not was not to do with it being a *.doc. I copied one of the tables into *.docx and saved the file. Then copied it into Scrivener. Again I got same result.

Please let me know if you require anymore details.

Cheers.

You probably already know, but just for the sake of documentation:

Table column width properties are still not being preserved in 029.