Created attachment 41291 [details]
document to reproduce the bug case

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.

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.

.

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("com.sun.star.drawing.ControlShape")
	oController = ThisComponent.getCurrentController
	oControlModel =
ThisComponent.createInstance("com.sun.star.form.component.FixedText")
	oShape.setControl(oControlModel)
	ThisComponent.getDrawpage.add(oShape)
	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

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.

fs-> msc: please verify in CWS dba22b

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

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

thanks for this fix

You can close it


Mechtilde

reopen - I can still reproduce with OOo 2.2RC1 on WinXP

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:

java.lang.NullPointerException
        at com.sun.star.wizards.document.Control.getPreferredSize(Control.java:230)
        at com.sun.star.wizards.document.Control.getPreferredWidth(Control.java:178)
        at
com.sun.star.wizards.form.FormControlArranger.insertLabel(FormControlArranger.java:468)
        at
com.sun.star.wizards.form.FormControlArranger.positionControls(FormControlArranger.java:333)
        at
com.sun.star.wizards.form.FormDocument$ControlForm.initialize(FormDocument.java:362)
        at
com.sun.star.wizards.form.UIControlArranger$ArrangeImageList.itemStateChanged(UIControlArranger.java:236)
        at com.sun.star.wizards.ui.ImageList.fireItemSelected(ImageList.java:411)
        at com.sun.star.wizards.ui.ImageList.setSelected(ImageList.java:563)
        at com.sun.star.wizards.ui.ImageList.mousePressed(ImageList.java:662)
        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
com.sun.star.wizards.ui.event.MethodInvocation.invoke(MethodInvocation.java:84)
        at
com.sun.star.wizards.ui.event.AbstractListener.invoke(AbstractListener.java:83)
        at
com.sun.star.wizards.ui.event.CommonListener.mousePressed(CommonListener.java:105)
        at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method)
        at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:183)
        at $Proxy75.execute(Unknown Source)
        at com.sun.star.wizards.ui.UnoDialog.executeDialog(UnoDialog.java:586)
        at com.sun.star.wizards.ui.UnoDialog.executeDialog(UnoDialog.java:623)
        at com.sun.star.wizards.form.FormWizard.startFormWizard(FormWizard.java:297)
        at
com.sun.star.wizards.form.CallFormWizard$FormWizardImplementation.trigger(CallFormWizard.java:107)

reassign to the right developer

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.

HTH.

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

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.

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.

fixed in CWS revctrlwiz:
svx/inc/sdrpagewindow.hxx 1.2.88.1.8.1
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx 1.5.44.2.4.1
svx/source/svdraw/sdrpagewindow.cxx 1.3.44.2.8.1
svx/source/svdraw/svdpagv.cxx 1.54.70.2.8.1

submitted issue 74694 as follow-up for the overlapping table controls.

fs-> msc: please verify in CWS revctrlwiz

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

Checked - 2.2RC1 broken, 2.2 released good.
Closing.