Created attachment 49634 [details]
test case

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 ***

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 ? 

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?

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?

fs->aw: Not sure I understand your question? What do you mean with "its xForm"?

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->1.6.26.1 in
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx.

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.

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
error-prone.
With (b) it will always work, but how to make it visible again? No Object -> no
selection...

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
possibilities...

well, we have a trinity between SdrObjects (aka shapes), controls, and control
models.

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.

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

ok, I will try it.

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 ;-)

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?

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.

>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 ...
                                          ^^^^^^^

in the 80s, invisible content was high tech. Today it is a security issue. Just
my $0.02

My own 2 € cents ...

Switching visibility of some controls in a complex form has been used since a long 
time.
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 
visibility.
So really, there is regression if it does not work anymore.

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?

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.

> 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?

IMHO this issue is a duplicate of Issue 82791 and not of Issue 72609

Issue 72609 is about dialog controls, not form controls.

*** Issue 82791 has been marked as a duplicate of this issue. ***

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

Created attachment 49723 [details]
patch file

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? 

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
Layer.

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.

Created attachment 49729 [details]
patch file - v2

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
obvious
  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 )

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 ...

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.

patch committed to CWS dba24d - thanks for contributing it.

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.).

fs->noel: should mention the revision, shouldn't I ... 1.8.204.2 contains your
patch plus my changes to catch the exceptions, in case you want to try it out.

Frank, I will check it, thanks for committing it :-)

ehm - 1.8.204.4, please

frank, works as expected now

fine. The fix will materialize in 2.4 then. Thanks.

fs-> cn: please verify in CWS dba24d

reassign to msc

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:
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fdba24d

Checked w/ OOo300 m_1, XP

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

Closing

(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..)

The RFE mentioned is opened as 
http://www.openoffice.org/issues/show_bug.cgi?id=92640