Issue 73115 - "integration.forms.ListSelection" test do not run anymore
Summary: "integration.forms.ListSelection" test do not run anymore
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m198
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.2
Assignee: Frank Schönheit
QA Contact: issues@dba
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2007-01-04 11:31 UTC by Frank Schönheit
Modified: 2007-05-07 10:56 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2007-01-04 11:31:55 UTC
- Run the forms.integration.ListSelection test by issuing "dmake" in
  forms/qa/integration/forms, followed by "dmake run_ListSelection"
=> on the console, you'll find multiple outputs saying that the test was not
successful
   due to NoSuchElement exceptions.

In non-product builds, you'll also get various assertions saying "SdrPageView*
ist NULL", from sc/source/ui/view/gridwin5.cxx, line 392.

If you examine the documents created by the test, you'll see that no controls
are created at all (there should be 5 buttons and one list box on each sheet).
In fact, that's the reason for the above mentioned exception, which is thrown
when the script tries to obtain those controls.

Also, if you break the test script before it closes the document, you can play
with the document: You'll notice that you're completely unable to create any new
form controls, nothing will happen if you try to.
Comment 1 Frank Schönheit 2007-01-04 11:32:59 UTC
That's probably a regression of CWS aw024. In m193, the test works fine, in m194
it doesn't.
Comment 2 Frank Schönheit 2007-01-04 11:34:48 UTC
Note that there are other tests in the integration.forms package, which also
create controls in spreadsheet documents, but can run successfully. For
instance, the integration.forms.RadioButtons test successfully creates a
spreadsheet with some radio buttons, and tests them.
Comment 3 Frank Schönheit 2007-01-04 11:44:21 UTC
difference between this script and others:
the ListSelection test removes sheets from the document. After this operation,
the document seems to be somehow corrupted.

In particular, the test creates an empty spreadsheet, and calls
XSpreadsheets.removeByName with the name of the second sheet. After this, the
first (still existing) sheet is somehow corrupted. You can see this my moving
the mouse over the document after the first "removeByName" call: from this call
on, every mouse move will trigger the above-mentioned assertion.
Comment 4 Frank Schönheit 2007-01-04 12:23:29 UTC
fs->aw, nn: I'm lost in the drawing/spreadsheet object hierarchy here ...

When a sheet is removed via UNO API, then ScDrawLayer::ScRemovePage broadcasts
aScTabDeletedHint. This is observed by ScDrawView::SFX_NOTIFY, which then does a
HideSdrPage. Unfortunately, this means that now the drawing layer is somehow
corrupt, which can be observed by hovering with the mouse over the active sheet
- this asserts, since now the ScDrawView does not have a valid SdrPageView
anymore - it was deleted and reset in HideSdrPage.

Hmm. Comparing this where a sheet is deleted manually, there is *also* a
HideSdrPage called, which also resets the SdrPageView member to NULL.
However, in this scenario, there's an additional ShowSdrPage called, which
re-creates it, with the following stack:
  SdrPaintView::ShowSdrPage()
  FmFormView::ShowSdrPage()
  ScTabView::TabChanged()
  ScTabView::SetTabNo()
  ScViewFunc::DeleteTables()

fs->nn: Is it possible that removing sheets by API is missing some restoration
of the current sheet, or something like this?
Comment 5 Armin Le Grand 2007-01-05 13:25:56 UTC
AW->FS, NN: From DrawingLayer perspective, the DL View does not necessarily have
to have a SdrPageView. This would be a DrawingLayer which does not visualize a
page (yet/no more). The applications should work with that, it is no good idea
to somewhere remember the SdrPageView or access the GetSdrPageView()-result
without test.

Well, from the applications view, these simply do not do that correct in all
places and often rely on an SdrPageView being there, so the usual (not good)
workaround is to create a new, empty SdrPageView by showing a new, empty page.
At least that this works shows that in principle, the SdrPageView is not
remembered, but only (hah!) places where GetSdrPageView() result is not tested
need to be looked for...
Comment 6 niklas.nebel 2007-01-08 16:46:30 UTC
In Calc there always is a page (except temporarily during an operation such as
deleting a sheet).

The problem was the change from HidePagePgNum(nDelTab) to HideSdrPage(), because
nDelTab isn't always the page that's visible.

Fixed on CWS "aw039", changed: drawvie3.cxx 1.10.34.1.
Comment 7 Armin Le Grand 2007-01-10 10:25:59 UTC
AW->FS: please review, install sets are all ready
Comment 8 Frank Schönheit 2007-01-10 14:33:24 UTC
verified in CWS aw039
Comment 9 marc.neumann 2007-05-07 10:56:09 UTC
Hi,

this is fixed in the current master. The current master is available at
http://download.openoffice.org/680/index.html

I close this issue now.

Bye Marc