Issue 113730 - form controls grouped with non-form-control-objects are invisible
Summary: form controls grouped with non-form-control-objects are invisible
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: DEV300m84
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: eric.savary
QA Contact: issues@dba
Keywords: oooqa, regression
Depends on:
Blocks: 111112
  Show dependency tree
Reported: 2010-08-08 14:57 UTC by eremmel
Modified: 2010-10-04 08:15 UTC (History)
5 users (show)

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

Base doc with two froms. One with grouping does not show group (21.38 KB, application/vnd.oasis.opendocument.text)
2010-08-08 15:00 UTC, eremmel
no flags Details
simplified document to reproduce the bug case (9.95 KB, application/vnd.oasis.opendocument.text)
2010-08-13 09:01 UTC, Frank Schönheit
no flags Details
proposed patch which holds up the old paradigm after reload (1.52 KB, text/plain)
2010-09-08 11:38 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description eremmel 2010-08-08 14:57:35 UTC
Dev 300m86

I've a from with a grouping of three objects. Opening/Editing the form does not
show the objects on the form. Clicking in the area show the boundary markers.

Ungrouping makes all visible.

I tried to make a test cast from scratch but that seems to work. So it might be
compatibility issue.

I copied the form (without any database/tables) to a base from and there it
showed the same behavior. Please find a document attached with two forms: one
with grouping and the other with ungrouping. Form names point to test case.
Comment 1 eremmel 2010-08-08 15:00:16 UTC
Created attachment 71010 [details]
Base doc with two froms. One with grouping does not show group
Comment 2 r4zoli 2010-08-09 07:02:01 UTC
I tested it with OOO330_m2, I can confirm this behavior.

One question remained how to create such grouping.
I can not reproduce it on empty form, please give a step by step description.

Comment 3 eremmel 2010-08-09 09:49:33 UTC
I notice that the grouping is shown OK when I open the document with 3.2.1
(OOO320m18, 9502).

Played around and found a scenario with 300m86:
1. Create form via wizard on a table and take a Grid on table.
2. Draw a Rectangle (or other Drawing object, tested not all objects).
3. Make a grouping on both
4. Save and close form
5. Reopen form
Now the drawing object is not shown.

Other observations:
A. When the grouping is on a grid of sub-form and a Drawing object, the grid is
not shown as well until one hovers over the grid with mouse.
B. Not showing control/objects also happens when group is made between other 
Form Control and Drawing object.
Comment 4 drewjensen.inbox 2010-08-09 13:40:24 UTC
Hi - well, I can confirm the problem w/ the attached file (which actually causes
a different issue because of the using DEV330m_2 / Ubuntu.

Comment 5 r4zoli 2010-08-09 13:51:34 UTC
I confirm it, it seems to me as regression.
I created new form in OOo 3.2.1 as eremmel described, and it works in this version.

Opened form in OOO330_m3 and DEV300_86, the subform not shown until I went over
with mouse pointer.
The subform added object area color can be set, form not show it.

It is a regression.

Assign developer.
Comment 6 Frank Schönheit 2010-08-13 08:58:56 UTC
Can reproduce in OOO330.m3, will nominate as 3.3 blocker.
Comment 7 Frank Schönheit 2010-08-13 09:01:06 UTC
Created attachment 71090 [details]
simplified document to reproduce the bug case
Comment 8 Frank Schönheit 2010-08-26 14:35:11 UTC
in fact the problem here seems to be the grouping of form controls with other
objects - in such a case, both object types are invisible.
Comment 9 Frank Schönheit 2010-09-07 14:13:00 UTC
fs->aw: thanks for looking into this
Comment 10 Armin Le Grand 2010-09-07 14:29:19 UTC
AW: Does not happen in DEV300m84 with adding a shape and a form control and
grouping them. Does not happen in OOO330m7 when doing so. Trying the example
Comment 11 Armin Le Grand 2010-09-07 14:33:48 UTC
AW: Does happen with DEV300m84 when constructing group, saving and reloading.
Preparing SW...
Comment 12 Armin Le Grand 2010-09-07 14:47:45 UTC
AW: Added FS to cc...
Comment 13 Armin Le Grand 2010-09-07 16:01:57 UTC
AW: In SW (0) is hell layer, (1) is heaven and (2) is control layer. When
constructing such a group (case A) initially the rect and the control are on
layer (2) (probably since some 'code' in grouping in SW does so ?!?). After
reload (case B) , rect is on (1) and control is on (2), as it should be.
The visibility test for VOCs (ViewObjectContactOfSdrObj::isPrimitiveVisible)
uses rObject.GetLayer() to check if the object is visible in this layer paint.

In case (A) the rectangle and the control get both painted in the FormLayer
repaint which is not correct, but works.

In case (B) the SdrObjGroup::GetLayer() implementation returns zero since the
childs have different LayerIDs. Thus, the group is handled in hell layer
repaint. Nothing is painted since the repaint also checks the
::isPrimitiveVisible calls for the single members.

Both is wrong, but it worked in previous versions, so something must have
changed which makes the already wrong behaviour in both cases now break in the
2nd case. Would it be better to find out why this ever worked or to risk to
correctly do it now...? Looking further...
Comment 14 Armin Le Grand 2010-09-07 17:53:52 UTC
AW: Found the code in SW which forces both objects on a single common layer, the
control layer, when SW is grouping objects. It's in SwDrawContact::SwDrawContact
and there is a comment which says (in german, translated here):

'controls have to be in the control layer always, also true for groups
containing controls'.

AW->OD: It looks as if this paradigm is not (or no more) applied after reload in
current versions. Look for the usages of CheckControlLayer in SW. Please have a
look if this is no more done at reload by purpose. If no, You may know best
where to reapply it. If Yes, we need to solve this differently.
Comment 15 Armin Le Grand 2010-09-07 18:10:41 UTC
AW->OD: The better solution would be not to 'bend' the LayerIDs for groups, but
to define that groups cannot be invisible by their LayerID (which may not be
uniquely defined with more than one object). Their content will be checked on
single SdrObject level for visibility anyways. This would be two steps:

- Remove all 'bendings' of SdrGroupObj LayerIDs in SW
- Implement a ViewObjectContactOfGroup::isPrimitiveVisible which is the same as
ViewObjectContactOfSdrObj::isPrimitiveVisible but without the first test for

I am just not sure if that bigger change is okay for OOO3.3; when the 'bending'
was just fallen out in the current version, it may be safer to re-install that one.
Comment 16 Armin Le Grand 2010-09-08 11:36:15 UTC
AW: Tried to add code to re-establish the mentioned paradigm (at
SwDrawContact::ConnectToLayout), but did not work in a first try.

Problem seems to be that the code for 'bending' in SwDrawContact::SwDrawContact
is too early at load time; it gets called when the import is creating the empty
group object, and does nothing there due to missing content. The content is
added later. Thus, i decided to take a look at SwDrawContact::_Changed which
anyways. This seemed to be the right place to update the 'bending'. Tried and works.

I am not sure what side effects this may have, thus OD will have to check if
this is okay for OOo3.3. I will add the proposed fix as a patch.
Comment 17 Armin Le Grand 2010-09-08 11:38:07 UTC
Created attachment 71609 [details]
proposed patch which holds up the old paradigm after reload
Comment 18 Oliver-Rainer Wittmann 2010-09-13 13:19:06 UTC
Patch looks good.
Small adjustment: Assure that the group object keeps its visibility/invisibility
when changing its layer ID to the control layer.

Issue is planned to be fixed in cws sw33bf09
Comment 19 Oliver-Rainer Wittmann 2010-09-13 13:54:48 UTC
fixed in cws sw33bf09 - changed file:
/sw/source/core/draw/dcontact.cxx, change set 66542fad855f
Comment 20 Oliver-Rainer Wittmann 2010-09-13 14:25:14 UTC
od->es: Checked in internal installation set of cws sw33bf09 - please verify.
Comment 21 Oliver-Rainer Wittmann 2010-09-13 14:29:08 UTC
taking back again
Comment 22 Oliver-Rainer Wittmann 2010-09-13 16:31:21 UTC
fix failed :-(
Comment 23 Oliver-Rainer Wittmann 2010-09-14 10:59:34 UTC
Further corrections are needed.

Deeper investigation reveals that the defect has been introduced by the changes
for issue 161701
Comment 24 Oliver-Rainer Wittmann 2010-09-14 15:34:56 UTC
applied further corrections - changed files:
change set 879c4cd0e18b
Comment 25 Oliver-Rainer Wittmann 2010-09-15 07:30:37 UTC
od->es: Checked in internal installation set of cws sw33bf09 - please verify.

notes for testing:
Please check further functions of drawing groups which contain control object.
- editing group
- inserting/removing control objects to/from existing drawing groups
- create/edit drawing groups which itself contain drawing groups
- repeat of tests at the created test documents after a save-close-load cycle
Comment 26 eric.savary 2010-09-16 14:25:03 UTC
Verified in CWS sw33bf09
Comment 27 eremmel 2010-10-04 07:47:26 UTC
Is working in OOO330m9 (Build:9529)
Comment 28 Frank Schönheit 2010-10-04 08:15:10 UTC
then let's close it - thanks for the feedback