it helps if you report that you test a trunk nightly

I reproduced the crash on Windows 7 with my local recent build from trunk (rev. 1585261).

I can not reproduce the crash with AOO 4.1.0 RC2 or AOO 4.1.0 Beta.
Thus, it seems that this issue is not relevant for our AOO 4.1.0 release

I can't reproduce it on MacOS as well, with RC2

We don't accept showstopper from trunk!!! Can you confirm it on the RC2?

Sorry!
No problem with
AOO410m15(Build:9761)  -  Rev. 1585426
2014-04-01 13:50 - Linux x86_64
Debian

Armin: Could you have a look? I assume that the introduction of the new background attributes caused this issue.

Sure, taking a look...

This is strange; just checked my build of the branch alg_writerframes where I developed this; it works flawless there. Preparing sw with debug...

(In reply to Armin Le Grand from comment #7)
> This is strange; just checked my build of the branch alg_writerframes where
> I developed this; it works flawless there. Preparing sw with debug...

It was just a guess from my side that the integrated work from branch alg_writerframes is related to this defect.

Olli, you are right; I re-checked (afetr looking at the code) and can reproduce in my cws, too. A first point to take action is SfxTabDialog::ActivatePageHdl where there is a fallback to 1st page when page is not found, but that has an error. Activating and asserting that.
Then it is indeed okay in a picture frame to have the Background TabPage, but it seems not to be added/ inserted. Looking deeper...

From the code it's clear that the same should happen with OLEs, checked, indeed. The mentioned fallback to 1st page works, I will add this to the fix.
The basic problem is that the SwFrmDlg is obviously used for the types DLG_FRM_STD, DLG_FRM_GRF and DLG_FRM_OLE. Somehow I missed the GRF and OLE cases, thus that dialog has no longer a Background TabPage.
The alternatives are:

(a) Add that TabPage again (only commented out for now) and use in the two cases
(b) Extend OLE and GRF cases to also support the new fill attributes

While (a) is more simple, (b) is the way to the future; when we want to align graphic objects bewteen Writer and DrawingLayer we will have to support the DrawingLayer FillStyles anyways, thus I would prefer (b). The extra work will be to apply the needed changes to the involved frames.

Olli, comments?

DLG_FRM_OLE uses the same shell as DLG_FRM_STD, the SwFrameShell, so the SwGrfShell::Execute uses the correct SfxItemSet using the ranges XATTR_FILL_FIRST, XATTR_FILL_LAST for values and SID_COLOR_TABLE, SID_BITMAP_LIST for the XLists.

DLG_FRM_GRF uses the SwGrfShell, there these are missing. These need to be added (and I will need to sort the IDRanges...)

Okay, that works. Lets see what else will be needed tomorrow.

(In reply to Armin Le Grand from comment #10)
> From the code it's clear that the same should happen with OLEs, checked,
> indeed. The mentioned fallback to 1st page works, I will add this to the fix.
> The basic problem is that the SwFrmDlg is obviously used for the types
> DLG_FRM_STD, DLG_FRM_GRF and DLG_FRM_OLE. Somehow I missed the GRF and OLE
> cases, thus that dialog has no longer a Background TabPage.
> The alternatives are:
> 
> (a) Add that TabPage again (only commented out for now) and use in the two
> cases
> (b) Extend OLE and GRF cases to also support the new fill attributes
> 
> While (a) is more simple, (b) is the way to the future; when we want to
> align graphic objects bewteen Writer and DrawingLayer we will have to
> support the DrawingLayer FillStyles anyways, thus I would prefer (b). The
> extra work will be to apply the needed changes to the involved frames.
> 
> Olli, comments?

My preference s also option (b)

"alg" committed SVN revision 1587482 into trunk:
i124638 As a first step, avoid crash when a TabPage is not found for a TabDia...

Okay, going. I will commmit the fallback to 1st TabPage in TabPage dialog when target TabPage is not found, plus asserting this, to get rid of the crash in trunk...

"alg" committed SVN revision 1588308 into trunk:
i124638 support for DrawingLayre FillStyle for GraphicFrames and EmbeddedObje...

Added support for DrawingLayer FillStyle for Writer Graphic and EmbeddedObject frames, comitting. Done a lot of tests, too. The original EO and GRF frames only supported a simple color fill, this is now unified and due to that widely extended. Checkd back- and forth compatibility; the original AOOs can load more complex fillings than they could define via UI.
During checks I stumbled over PageBackground which for now has to be handled as an exception already (so far is the integration of the DrawingLayer FillStyles). I am thinking about it - shouldn't we consequently also change these to the DrawingLayer FillStyles for unification, too...?

Also thinking about page background - does it make sense to keep it on the old modes? I think not. Candidates also may be paragraph background and table fill/background

(In reply to Armin Le Grand from comment #18)
> Also thinking about page background - does it make sense to keep it on the
> old modes? I think not. Candidates also may be paragraph background and
> table fill/background

+1 for enhancing the other 'backgrounds', too
There is also row fill/background and cell fill/background

No crash with
AOO410m18(Build:9764)  -  Rev. 1589052
2014-04-22 12:11 - Linux x86_64
Debian

Looking for Paragraph and PageBackgrounds...

Preparing commit of Paragraph/PageBackground changes for Writer, building mac and Linux versions...

Builds done, additional changes to sources to make it work applied. Checking tiny repaint gaps on win...

"alg" committed SVN revision 1599233 into trunk:
i124638 Second step of DrawingLayer FillAttributes for Writer objects, now ad...

Saw that visualization with AA on/off and on the three main plattform differs, need to correct that. Example: New Writer, type 'dt' + F3 (auto text expand), give paragraph a gradient, type and add SIFT+Returns -> paint errors on mac and linux, on non-AAed win, too. Investigating...

"alg" committed SVN revision 1599676 into trunk:
i124638 Corrected paints of Writer Frames with DrawingLayer FillAttributes fo...

Saw that in Writer on trunk the ColorTable is not there when working with SdrObjects. This has to do with the order of initialization of DrawModel and DocShell. The DocShell gets SfxPoolItems set (*not* in a SfxItemSet (!)) and the list ones for color and others need to be there for the ToolbarControls to find these. The initializations for these are widely distributed over writer and behave different depending in which order DrawModel and DocShell are created (!). Trying to cleanup that stuff...

"alg" committed SVN revision 1600568 into trunk:
i124638 Corrected relationship between DrawModel and DocShell in Writer, made...