Issue 44565

This is designed so. The writer embedded object stores the visual area
internally. This visual area affects graphical replacement of the object. That
means that this is a valuable part of the document information, so changing of
the visual area in edit mode sets the embedded document to modified state. Next
time the document is activated the position used on last storing should be used.

> This is designed so.

So the design is bad and has to be resigned. 

fs->mav: I understand the technical explanation, however, from a user's point of
view, this is a usability issue. And user's usually don't care for technical
explanations.

May I suggest that we somehow control that for documents embedded in databases
docs, scrolling does not affect the Modified flag, while for "real" embedded
documents, it does?

We could controls this by an extra flag (which we would have to set when loading
the document), or something like this.

MAV->MSC: More specific criticism would be much more helpful. At the current
state I still do not see why is the design so bad.

MAV->FS: It is not just about the technical part. This is a logic of embedded
object behaviour that in result affects user.

An embedded object consists from replacement representation it provides to a
container and own contents ( the replacement representation might be optional ).
If somebody activates starwriter embedded object inplace, scrolls down and
deactivates the object, the replacement image should reflect the changes, the
embedded document should store those changes so that the next time user
activates it the correct place of the document is shown. The same is true for
outplace activation. For objects that support inplace activation it seems to be
the only reasonable way.

The only alternative in object behaviour that I see is acceptable only for
outplace activation. In this case object document is always activated in
specific hardcoded scrolling position and the replacement image is always
generated only for this position. In this case the scrolling position is no more
a part of the embedded document information, so the scrolling does not change
the modified state of the object.

Although technically it is no big problem to implement triggering of the second
behaviour for embedded objects, from my point of view the second way brings no
benefit, moreover, it contains only minuses:
- It is not possible for user to let the object be activated at a specific
position next time. For database it is even more valuable loss since by changing
of the scrolling position in 'edit' mode user could specify the way the form is
opened in 'open' mode, of course the scrolling in 'open' mode can not set the
modified flag since the object is readonly.
- ( questionable ) As I understand the left bottom window in the database
component is designed to show form preview ( at least it was used for this
reason sometimes ago ), means embedded object replacement image, if this feature
is going to be activated then the previous entry becomes even more valuable.

I just wanted to clarify my position since this change seems to be questionable
for me even from user point of view. But as I have mentioned, if database
requires the second way behaviour for forms, it should be no big problem from
technical point of view.

preface: I think the forms/reports embedded in databases are a rather special
case for embedded objects, since the fact that those "sub-documents" are
implemented the same way as, say, a Writer doc embedded in a Calc doc is
implemented, is a pure technical coincidence, which we should not bother the
user with.

That said, I completely agree that the feature to *remember* the scrolling
position is very valueable, in both "usual" outplace objects, and in database
sub documents. This holds for both the preview and the normal opening.
However, what the user most probably does not expect is that a simple scrolling
modifies the document - this is simply not expectation conformant.

So, what I would love most is something similar to the behaviour of OOo 1.x for
*normal* documents:
Scrolling (and other view-related actions such as zooming) did not affect the
"modified" flag. However, they were stored together with the document, and
restored upon next reload.
That is, if you scrolled and saved, the scroll pos was restored. If you scrolled
and didn't save (e.g. because you didn't do any other modifications), then the
scroll pos was lost without further warning.

In my opinion (Marc, I'd be interested in yours), this would be the best
solution: Store the scroll position, and other view-related settings, together
with the document, and restore it on next load. But, and that's the important
change, do *not* flag a document as modified just because of scrolling.

Mikhail, can we implement something like this? Perhaps a flag which we pass to
the embedded object, saying something like
"DoNotModifyThisDocumentJustBecauseTheUserScrollsTheView = sal_True"?

As I have mentioned, introducing of such an argument will not need much time.

I agree that the database form is a special kind of embedded object, and didn't
whant to mix it. I have just provided the writer embedded object as an example
of embedded object behaviour. And a user who is used to embedded objects might
expect the same behaviour from the form, that actually looks pretty like an
embedded object in it's behaviour.

In case of using of this new argument the design still looks for me slightly
logically inconsistent, I mean if a user opens a form for editing, then all his
changes should trigger the document modified flag. And if the user whants just
to scroll through the document he could open the form only for viewing.
From other side not all of the designs are logically consistent, just because
sometimes users do not follow logic or use different logic in their
expectations. So if the solution with the new argument is more preferable I
shall introduce it.

fs->mav: let's introduce this flag ...

As the result of discussing the problem with FS and MBA it was decided that the
fix should be done for "OOo Later", FS has already confirmed this with MSC.
Changing the target.

Reset assigne to the default "issues@openoffice.apache.org".