Multi-Page Table Losing Rows in Some Views

[PBJ]

I have a three-page table set up as a form. This form is sent by email to
many different users, both in-house and out-of-house. I've set the row and
page -break parameters so that rows do not break across pages. Users have had
no problem with it at all: It reflows and rebreaks just fine.

One of our subcontractors, however, consistently returns the form weirdly
altered. The form is still locked so that only text fields are accessible,
but now the entire table grid has shifted up on the page. More importantly,
you can only see the whole table in "Normal" view. In "Page Layout" view, you
can only see the first page of the table--the other pages are completely
blank, and the last row on the first page actually cuts off in the middle.
You can't print the entire table in ANY view.

There are also other minor changes in row shading, etc. The subcontractor
SWEARS they haven't done anything to the form, and indeed, we have resupplied
them with fresh templates a few times, but whenever they fill them out, they
come back in the same corrupt way, so I'm tempted to believe them. (There's
no reason for them to keep freaking out the form iin the same way each time.)
I've checked the properties of the row that is breaking in the returned form,
and its setting has changed so that it CAN break across pages.

Help! Any suggestions what's going on? I should mention that we work on Macs
in house (and that that's the platform on which the table was developed), but
that there's no guarantee whether vendors open it in Mac or PC. Might this be
creating a corruption issue? If so, it's kind of weird, because when I open
the form at home on my PC, it works just fine.

Help! Any ideas? We're despearate (and annoyed)!

 

[Suzanne S. Barnhill]

Assuming that the document is not actually protected (for forms), my guess
is that the errant subcontractor, working in Print Layout view, has
accidentally nudged the table handle, resulting in making the table wrapped.
Go to the Table tab of Table Properties and make sure that the text wrapping
is set to None.

 

[PBJ]

Thanks for the reply, but unfortunately, the table properties do show text
wrap as "none." (And actually, since this is set up as a form, the table was
locked to limit user access to specified text-entry fields.) So I guess I'm
still stuck. I think my annoyance is changing into mostly puzzlement--I mean,
this is just plain weird. Maybe they're just playing cruel mind games with
me, but without the kinkiness of mind games in the movies. Pretty low-level
mind games.

Thanks again, though!

 

[Suzanne S. Barnhill]

That's what I get for multi-tasking. <g> Considering the information you've
provided, I don't see any reasonable explanation unless the subcontractor
*is* playing mind games and has actually unlocked the form and then
reprotected it. You do know, don't you, that protection can be removed from
even a password-protected form by inserting it into a fresh document? But
assuming that's not the case, could this happen just as a result of adding
more text to a field than will fit? Have you set exact row heights?

If you can email me a sample of the messed-up form, I'll see what I can find
out.

 

[PBJ]

Hmm. I didn't know that copying and pasting a form into a new document
unlocked it. I wonder if that's what they're doing.

Meanwhile, I'm sending you some samples at the website in your signature. If
you can help, great, if not, I won't be hurt. You've already been great.

Michael Link

 

[Suzanne S. Barnhill]

I did receive your documents and have replied. Note, for future reference,
that you can get my direct email by clicking on my name in a message.

For the sake of the thread, it turned out that the table in the corrupt
document had somehow become framed. Removing the frame (mostly) solved the
problem.