Issue 83611 - uno controls can't be made 'really' invisible
Summary: uno controls can't be made 'really' invisible
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.3
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.4
Assignee: marc.neumann
QA Contact: issues@framework
: 82791 (view as issue list)
Depends on:
Reported: 2007-11-13 15:55 UTC by noel.power
Modified: 2008-08-10 23:05 UTC (History)
5 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

test case (8.22 KB, application/vnd.oasis.opendocument.spreadsheet)
2007-11-13 15:56 UTC, noel.power
no flags Details
patch file (1.64 KB, patch)
2007-11-18 12:05 UTC, noel.power
no flags Details | Diff
patch file - v2 (1.84 KB, text/plain)
2007-11-18 16:03 UTC, noel.power
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description noel.power 2007-11-13 15:55:55 UTC
setting the Visible property to false for a control seems to have not exactly
the effect I would expect. 

On calc and writer I see the following behaviour ( reproduced on 2.3 and also
m231, sorry I didn't try any other milestones )

setting the visible property of the control to false results in the control
still being displayed, e.g. it is still drawn on the document but you can get a
cursor inside the control ( or in the case of calc you can click on a cell
'behind' the control ) and see the cell selected. 

perhaps I am doing something strange, I don't know, I will attach a document
with a macro to demonstrate ( just press the button on the attached document to
toggle the visible property of the control )
Comment 1 noel.power 2007-11-13 15:56:43 UTC
Created attachment 49634 [details]
test case
Comment 2 Frank Schönheit 2007-11-14 06:01:54 UTC
Working with the controls directly, instead of the control models, is not a
supported way, and can (and will) lead to all kind of undesired side effects.
When you want to change the appearance/behaviour of a control, you always need
to tell its model.

Which implies that form controls need a Visible property, which they currently
don't have. There is issue 72609 which requests such a property for all
UnoControlModel implementations. Once this is implemented, form control models
will automatically inherit the property, so I mark this issue as duplicate.

*** This issue has been marked as a duplicate of 72609 ***
Comment 3 noel.power 2007-11-14 10:07:54 UTC
Frank, thanks for the info, unfortunately this introduces a nasty regression for
me because this used to work reliably in 2.0, 2.1 & 2.2 and it appears only
stopped working recently

is there anyway at all to work around this ? 
Comment 4 Frank Schönheit 2007-11-14 10:11:18 UTC
Interesting to know it worked before ...

Armin, with the new architecture in the drawing layer, is there any way how to
make shapes/controls invisible in a document?
Comment 5 Armin Le Grand 2007-11-14 11:40:29 UTC
AW->FS: The writer moves shapes he wants to hide to invisible layers. This works
fine. but in the general case You might not know if there is a invisible layer
You can use.
Unfortunately there is no simple visibility flag at SdrObjects. I would be
interested how it worked before. Frank, could You find out what chages to the
visibility in UnoControlModel did to hide the control in question? Maybe it's
xForm was deleted?
Comment 6 Frank Schönheit 2007-11-14 14:41:14 UTC
fs->aw: Not sure I understand your question? What do you mean with "its xForm"?
Comment 7 Frank Schönheit 2007-11-14 14:56:36 UTC
The change might be related to the changes done for issue 74895, where the
checkin comment says
"UnoControlWindowContact::doPaintObject: let painting the control depend on
its visibility, not on its design mode (they do not always correlate)"

Noel, you might want to try to locally revert the changes 1.6-> in

However, in general I prefer a real solution, not a hack. As said above, there
simply currently is no visibility support for controls. The fact that this
worked before when using the control's setVisible is an implementation detail,
which I would not like to promote to an officially supported feature.
Comment 8 Armin Le Grand 2007-11-14 15:09:31 UTC
AW: There are two 'real' solutions:
(a) Add a visibility state to SdrObjects
(b) Delete/create the SdrObject based on visibility info outside DrawingLayer

Both have caveats:
With (a) the flag does not only need to be taken care of when painting, but also
interaction, mouse clicks, exports, etc. Not easy to implement water-proof, very
With (b) it will always work, but how to make it visible again? No Object -> no

So a 'hack' (*ahem*) may be not too bad: In ShouldPaintObject for FormControl
(this is the right place, not in DoPaintObject) SdrObjects, returning a 'false'
will not visualize it, but it will be selectable.

I think You need to define what is wanted, especially regarding the interaction
Comment 9 Frank Schönheit 2007-11-14 15:14:23 UTC
well, we have a trinity between SdrObjects (aka shapes), controls, and control

For consistency, a visibility flag belongs into the model, and the control would
simply respect it, as it does with all model changes. Also the painting done at
the shape would need to respect it, which shouldn't be too difficult. Still, the
shape (basically: the green rectangles) would continue to be visible - I do not
know how much of a problem this would be. I suppose it wouldn't, since we
probably talk about alive mode only, where they're not available, anyway.

Also, since the visibility would be a model property, it could be changed via
the property editor. Selecting the control model in the property editor would
easily be possible by selecting it in the form navigator, or selecing the shape
in design mode.
Comment 10 noel.power 2007-11-15 10:58:17 UTC
>Noel, you might want to try to locally revert the changes 1.6->

ok, I will try it.

Comment 11 noel.power 2007-11-15 10:59:25 UTC
right I see other comments indicate maybe this isn't strictly the right thing to
change? I guess I need to read those comments a little more closely ;-)
Comment 12 Armin Le Grand 2007-11-15 11:16:26 UTC
AW->FS: I think You talked about the control model, not the DrawingLayer model?
The i propose my solution (c) (formerly the 'hack'). Test visibility in
VOC::ShouldPaintObject, return false if not visible. Do not forget to call
actionChanged() when that flag of the control model changes at the VC. Selection
and editing (DrawingLayer side) will still be possible. How was it working
earlier? Werent't the controls also just hided by not painting them?
Comment 13 noel.power 2007-11-15 12:19:10 UTC
Frank FYI your suggested change reversion didn't work :-)

Armin you suggestion did work nicely :-) a quick hack in
ViewContactOfUnoControl::ShouldPaintObject seems to work fine ( of course as you
say the details of what happens when in design mode etc. need to be sorted out )

And Frank, yes I do agree with the Model approach, for various reasons this is
the only way to go ( I have been recently by hidden shapes/controls being
visible on imported MS documents ). But.. so, a shape would also have a visible
property right? and in the case of a control the control's (shape:visible)
property is influenced by the control model's ( unocontrolmodel:visible )
property? I guess I am just a little confused ( but very interested ) in what
the right way to separate these would be.
Comment 14 noel.power 2007-11-15 12:25:32 UTC
>the only way to go ( I have been recently by hidden shapes/controls ...
the only way to go ( I have been recently annoyed by shapes/controls ...
Comment 15 clippka 2007-11-15 12:58:25 UTC
in the 80s, invisible content was high tech. Today it is a security issue. Just
my $0.02
Comment 16 bmarcelly 2007-11-15 14:34:31 UTC
My own 2 € cents ...

Switching visibility of some controls in a complex form has been used since a long 
This code is working with npower's document on OOo 1.1.5 and 2.2.1 (I have both):

Sub SwitchVisible
Dim thisPage as object, thisForm as object
Dim myControl as object, myControlView as object
thisPage = thisComponent.Sheets.getByName("Sheet1").DrawPage
thisForm = thisPage.Forms.getByName("Standard")
myControl = thisForm.getByName("ComboBox")
myControlView = thisComponent.CurrentController.getControl(myControl)
myControlView.Visible = (MsgBox("Make visible ?",4) = 6)
End Sub

method .isVisible() is not available in version 1.1.5 but you can nevertheless switch 
So really, there is regression if it does not work anymore.
Comment 17 Frank Schönheit 2007-11-16 12:47:14 UTC
Noel, care to attach your patch (I still do not know whether we really want to
officially support this, but let's see)?

For the shapes: I don't think the shapes would have a visibility flag, I think
only the models would (and the controls respect the model's flag). From past
experience, I know that a shape which has a model, but no control, behaves as if
its invisible, except that you can mark it (and see the green markers, then).

However, we might be on the way to using another undocumented behavior here.
Armin, do you have an opinion? If the paint request for a shape does simply
nothing, will this (for all times) mean the shape is effectively transparent?
Comment 18 Armin Le Grand 2007-11-16 14:11:44 UTC
AW->FS: Frank, i already did, see above. You are mixing up the two involved
models here. Definition:
(MD): Model of DrawingLayer, this includes the SdrObjects. There is no
visibility switch at SdrObjects
(MF): Model of FormControls. It has a visible flag.

Since MF uses MD as implementation, it has somehow to reflect the visibility
flag of it's model objects. Since MD has no visibility model flag, it can do
this e.g. by not painting anything. This is possible since the implementation of
the visualisation side of MF uses own VC and VOC classes. not callint
DoPaintObject in an overloaded SdrObject or (much better) returning false in own
overloaded implementation of ShouldPaintObject is totally legal and will
suppress the object's visualisation -> it gets invisible.

Caution needs to be taken for the interactive part. Even when visualisation for
a SdrObejct is suppressed, it can be selected and modified.

Thus it is necessary to define how this part should behave. That's why i asked
how this part behaved in the past. HTH.
Comment 19 Frank Schönheit 2007-11-16 20:07:51 UTC
> not calling DoPaintObject in an overloaded SdrObject or (much better)
> returning false in own overloaded implementation of ShouldPaintObject
> is totally legal

Okay, that "legal" is what I wanted to know.

> Caution needs to be taken for the interactive part. Even when visualisation
> for a SdrObejct is suppressed, it can be selected and modified.

Yes, that's what I described above. I am pretty sure this is also the old
behaviour when switching the control to invisible worked.

Okay, we might want to add some to code to the painting to respect the control's
visibility, to fix this faster than with waiting for the control model's
visibility support.
Noel, have a patch?
Comment 20 bmarcelly 2007-11-17 10:38:59 UTC
IMHO this issue is a duplicate of Issue 82791 and not of Issue 72609

Issue 72609 is about dialog controls, not form controls.
Comment 21 Frank Schönheit 2007-11-17 21:00:16 UTC
*** Issue 82791 has been marked as a duplicate of this issue. ***
Comment 22 noel.power 2007-11-18 12:03:59 UTC
frank sorry about the delay, I only saw the mail now ( 'fraid I let iz mails got
to a mail account that I don't read all the time unless I am really expecting
something ), attaching patch now
Comment 23 noel.power 2007-11-18 12:05:15 UTC
Created attachment 49723 [details]
patch file
Comment 24 noel.power 2007-11-18 12:15:39 UTC
so the patch *seems* to work nicely with the attached test document but, I don't
know if this code is exercised e.g. when dialogs are used ( and I didn't try
that yet )

also, I am still very interested in an uno solution, clearly there is no
possibility of persistence of the visibility state without a property at the
model. ( and I am not talking about file format persistence although that of
course would need supported also if a new model property was introduced ) e.g.
if a control is made 'invisible' like in the testdocument above and one goes
into design mode the visibility state is 'lost' or 'reset' similarly if one
switches between sheets on the doc the same can be seen.

also for shapes ( e.g. autoshapes ( and I guess one could include
pictures/graphic objects ) with that ) it 'should' also be possible manipulate
their visabilty state ( although this would I think be new behaviour ) hence my
other comments previously.

saying all of that, if the patch is acceptable then I think it at least should
be applied as a *temporary* solution until such time as a 'richer' and more
complete solution is available.

regarding a new property for unocontrolmodel(s) ( and ignoring shapes for the
moment ), what is your honest opinion as to when that might hit the streets? 
Comment 25 Frank Schönheit 2007-11-18 12:46:06 UTC
one comment on the patch: please change it so that instead of returning true in
design mode all the time, the base class is called.

For the shape visibility, in particular for other shape types: Yes, this seems
to be a different story. Armin should have an opinion here, he's Mister Drawing

For the visibility property at the uno control model: You need to ask Carsten
for that (I put him on cc). It's targeted for 3.x, which is a potentially long
time. Not sure if Carsten has concrete plans here.
Comment 26 noel.power 2007-11-18 16:03:49 UTC
Created attachment 49729 [details]
patch file - v2
Comment 27 noel.power 2007-11-18 16:08:09 UTC
patch is slightly different from the orig one I attached, seems after removing
the  uno::QUERY and subsequent test of xControlWindow I changed it to
uno::QUERY_THROW and  failed to rebuilt & retest ( /me takes a big slap on the
wrist ). 
After building and doing a quick test with the previous version 2 things were
  a) no body is catching any exceptions from here
  b) rVOC.getExistentControl() can return NULL :-(

the latest patch promises to be more robust ( and also takes account of your
last comment )
Comment 28 Frank Schönheit 2007-11-18 21:10:05 UTC
a) - ehm, yes. And as long as this is the case, nobody can tell me that
silencing exceptions which the own code cannot handle is an error. But that's
another story.
b) Yes - that's why it's called "getExistentControl" and not "getControl" :)

Okay, the patch looks as if committing it would still allow me to sleep this
night ...
Comment 29 Frank Schönheit 2007-11-18 21:21:39 UTC
will commit this to dba24d in a moment (need to add svx to my CWS first). Only
change I did is to adjust it to Roman style by removing the com::sun::star::foo
namespaces, and adding a "using com::sun::star::foo::XBar" in the respective
section at the beginning of the file.
Comment 30 Frank Schönheit 2007-11-18 21:47:40 UTC
patch committed to CWS dba24d - thanks for contributing it.
Comment 31 Frank Schönheit 2007-11-18 22:49:51 UTC
thinking more about it ... let's use the DBG_UNHANDLED_EXCEPTION thing to
silence the visibility check's potential errors. Not that I think they may
happen frequently, but I thought this about a lot of exceptions where our crash
reports showed I was wrong :-\

So, I committed a modification which silences any possible UNO errors. Noel, you
might want to check this still does what you need (it should, it works as (I
understand is) expected in the sample document you attached.).
Comment 32 Frank Schönheit 2007-11-19 08:30:59 UTC
fs->noel: should mention the revision, shouldn't I ... contains your
patch plus my changes to catch the exceptions, in case you want to try it out.
Comment 33 noel.power 2007-11-19 09:40:04 UTC
Frank, I will check it, thanks for committing it :-)
Comment 34 Frank Schönheit 2007-11-19 12:04:25 UTC
ehm -, please
Comment 35 noel.power 2007-11-19 13:12:58 UTC
frank, works as expected now
Comment 36 Frank Schönheit 2007-11-19 13:28:34 UTC
fine. The fix will materialize in 2.4 then. Thanks.
Comment 37 Frank Schönheit 2007-12-02 12:37:01 UTC
fs-> cn: please verify in CWS dba24d
Comment 38 marc.neumann 2007-12-18 12:17:08 UTC
reassign to msc
Comment 39 marc.neumann 2007-12-18 12:18:16 UTC
verified in CWS dba24d, load visibleProble.ods and click the button

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 40 drewjensen.inbox 2008-08-10 23:01:43 UTC
Checked w/ OOo300 m_1, XP

Ran the basic code supplied by bmarcelly against a ODS as expected.


(note - will open RFE regarding visible property at the unoControl model as it
is mentioned here many times but it appears that was not done..)
Comment 41 drewjensen.inbox 2008-08-10 23:05:04 UTC
The RFE mentioned is opened as