To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88878
------- Additional comments from [EMAIL PROTECTED] Thu May 8 11:09:00 +0000
2008 -------
jianhuajiao, after applying your patch, form controls are *always* visible in
design mode. This implies several problems, amongst others, it implies that the
user cannot open a context menu on a form control in design mode.
This is because your current patch always keeps the control's visibility in sync
with the model property. As outline above, this should not be the case - even if
the model's "Visible" is true, then there are situations where the control
*must* be invisible, due to side conditions. This side conditions include the
following (and maybe more):
- the control is in design mode
- the control is in a hidden section in the text document
- the control is on a layer which is not visible
So, I suggest you
(1) completely remove the WindowStateGuard changes in forms, which currently
ensure that a form control's visibility is always in sync with the model
property
(2) rename the Visible property to "EnableVisible", to indicate that it does
*not* control the visibility, but only the *allowance* to be visible
(3) introduce code in toolkit which ensures that the control's visibility is
switched *only* if the EnableVisible property changes from TRUE to FALSE,
but *not* if it changes from FALSE to TRUE.
However, I think even the last point might not be enough. Consider the following
scenario:
- a control is currently visible, and its model's EnableVisible property
is set to TRUE
- the model property is set the FALSE
=> the control becomes invisible
- the model property is set to TRUE
=> the control stays invisible
This result is certainly not desired.
So, in real, a control would need to *distinguish* between two cases:
- it became invisible because of a model property change
- it became invisible because some other instance called setVisible( false )
Consequently, we need a place where we distinguish between those two cases. One
possible solution would be that an VCLXWindow tracks the EnableVisible property
itself. That is, the model property EnableVisible is reflected in a boolean
member of VCLXWindowImpl, say mbEnableVisible. Those two are always in sync.
Also, another member is introduced, let's call it mbDirectVisible. This member
is modified in VCLXWindow::setVisible.
Then, whenever mbEnableVisible or mbDirectVisible change, the VCL window is set
to visible if and only if *both* members are TRUE.
(Note: With an approach like this, (3) from above does not need to be done
anymore.)
This should address all scenarios, in that one could modify either the model's
EnableVisible property, or directly call XWindow::setVisible, and always get the
result, no matter in which order you do this.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
