Issue 72429

Summary: repaint error in form wizard in bugdoc database
Product: Base Reporter: Frank Schönheit <frank.schoenheit>
Component: codeAssignee: marc.neumann
Status: CLOSED FIXED QA Contact: issues@dba <issues>
Severity: Trivial    
Priority: P2 CC: andre.schnabel, ht990332, issues, mdxonefour, pavel
Version: recent-trunkKeywords: regression
Target Milestone: OOo 2.2   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 73858    
Description Flags
document to reproduce the bug case none

Description Frank Schönheit 2006-12-09 21:02:06 UTC
- open the attached bugdoc
- start the form wizard
- on the first page, choose the "master" table and all fields
- on the second page, choose to create a sub form according to
  the existing relationship to the "detail" table
- on the third page, choose all "detail" fields
- on the "Arrange controls" page, choose "Columnar - Labels Left" layout for
  the master form
=> the layout is not created, and the document is not repainted anymore
Comment 1 Frank Schönheit 2006-12-09 21:03:01 UTC
Created attachment 41291 [details]
document to reproduce the bug case
Comment 2 Frank Schönheit 2006-12-09 21:04:33 UTC
update: The subform part is not necessary, simply let the wizard create a form
for the master table, and change the layout as said above.

Used to work in previous builds => regression

Note: "Version" field is not correct, this happened in m196, but m196 is not
available in the "Version" list.
Comment 3 Frank Schönheit 2006-12-09 21:06:09 UTC
fs->bc: I don't think this is your bug. In fact, I suppose this is a result of
CWS aw024 which was integrated into m194.
However, you are probably quicker in finding out what goes wrong in the wizard,
and which exceptions are thrown.
Comment 4 berend.cornelius 2006-12-11 11:35:54 UTC
Comment 5 berend.cornelius 2006-12-12 10:05:05 UTC
bc: error  was due to a NullPointerException that was thrown when the control
was queried with "getControl()". I tried to reproduce the bug with the following
Basic Code that describes how it occured:
Sub Main
	oShape = ThisComponent.createInstance("")
	oController = ThisComponent.getCurrentController
	oControlModel =
	oControl = oController.getControl(oControlModel)
	msgbox "Control is Empty: " & IsEmpty(oControl)
End Sub
However the Basic Script did not fail ("oControl" is not empty). According to fs
there is a timing problem that is not bound to occur in Basic.
bc->fs: As we discussed: to You
Comment 6 Frank Schönheit 2006-12-12 12:33:32 UTC
The fix for this was made with 71260. Since this one here has a reproducible
problem description, I don't mark it as duplicate, but include it in CWS dba22b.
Comment 7 Frank Schönheit 2007-01-04 10:39:02 UTC
fs-> msc: please verify in CWS dba22b
Comment 8 marc.neumann 2007-01-05 14:49:34 UTC
verified in CWS dba22b

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 9 Frank Schönheit 2007-01-14 19:12:52 UTC
*** Issue 73455 has been marked as a duplicate of this issue. ***
Comment 10 Mechtilde 2007-01-20 21:32:22 UTC
thanks for this fix

You can close it

Comment 11 andreschnabel 2007-02-19 13:50:15 UTC
reopen - I can still reproduce with OOo 2.2RC1 on WinXP

Comment 12 andreschnabel 2007-02-19 14:53:57 UTC
some aditional info. In some cases the error "seems" to be fixed, when following
the initial description.

I've been able to reproduce the bug in OOo2.2RC1 (Sun build, WinXP) and OOF680m8
(linux x86, pavels builds) using the following steps:
- open the attached bugdoc
- start the form wizard
- on the first page, choose the "master" table and all fields
- move on to step 5
- on the "Arrange controls" page, choose "Columnar - Labels Left" layout for
  the master form
- choose any other layout for th master form
=> the layout is not created, and the document is not repainted anymore

when choosing the second layout i get following errors on linux console:

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at Method)
        at $Proxy75.execute(Unknown Source)

Comment 13 marc.neumann 2007-02-19 14:54:23 UTC
reassign to the right developer
Comment 14 Armin Le Grand 2007-02-19 16:23:11 UTC
AW->FS: Took a look at
o:\OOF680\src.m8\svx\source\sdr\contact\viewobjectcontactofunocontrol.cxx but
did not really understand the changes. Comments to the m8 behaviour:

- Repaint problems start when 'as Data Sheet' is used; before that all works
well in m8 (at m7, after 'as Data Sheet' usage, paint errors occurr. Looks like
double boundaries. This hints on paints as Window and as MetaFileMechanism from VCL)
- Maybe a side effect of xForms with the DataSheet control (whichever this is).
Something with real windows and show/hides on parents and/or something like that ?!?

Comments/explanations to #i74523# from last week where suddenly VDevs appear as
target: This only happens when actively typing a line in SW (the app uses a VDev
there and did not give me a chance to fix that with reasonable performance...).
In the case the current bug, paint requests and VOCs should directly go to the
VCL Window. I know no situation where a VDev should be involved here, but who
knows the whole SW.

Comment 15 Frank Schönheit 2007-02-20 07:57:23 UTC
The stack pasted above indicates that the wizard is unable to find a certain
control, which also was the reason for the original incarnation of this issue.
(Unfortunately, the wizard is not able to recover from this error, but leaves
the document in an invalid state, with all controllers locked, so no paints
happen anymore.)
Comment 16 Frank Schönheit 2007-02-20 09:56:29 UTC
it's not really a non-existing control, but a corrupted one.

This issue is the outcome of different fixes for different other issues, at
least issue 72694, issue 74523, issue 72752 contribute to this problem here.
(The fix for issue 74523 was the last one, which triggered this one here.)

Still no non-hacky idea how to solve this, need to discuss with AW.
Comment 17 Frank Schönheit 2007-02-20 10:55:38 UTC
discussions with AW provided a way to fix this. Tried, works :). Neither issue
72694, nor issue 74523, nor issue 72752 re-appear after the fix. Going to check
in after the cwsadd operation finished ...

What is *not* fixed is the pixel-offsets which you get after repeatedly
switching the layouts - there's another issue, fixed on the SRC-branch by OD,
whose number I don't know at the moment.

What is also *not* fixed is, with the original description from above:
- switch the main form to a non-table layout
- switch it back to table layout
- the table controls of the main and the sub form overlap

This error was already present in m7, and thus I consider it a separate one,
which I'm going to file separately.
Comment 18 Frank Schönheit 2007-02-20 11:16:10 UTC
fixed in CWS revctrlwiz:
Comment 19 Frank Schönheit 2007-02-20 11:36:41 UTC
submitted issue 74694 as follow-up for the overlapping table controls.
Comment 20 Frank Schönheit 2007-02-20 13:27:58 UTC
fs-> msc: please verify in CWS revctrlwiz
Comment 21 marc.neumann 2007-02-21 13:56:25 UTC
verified in cws revctrlwiz

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 22 kpalagin 2007-04-21 14:41:58 UTC
Checked - 2.2RC1 broken, 2.2 released good.