Bug 94024 - ZOrder of Shapes stops increment after 65535 Shapes
Summary: ZOrder of Shapes stops increment after 65535 Shapes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: Other Windows (All)
: medium major
Assignee: Not Assigned
Depends on:
Reported: 2015-09-08 12:49 UTC by mmaurer
Modified: 2019-12-04 08:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description mmaurer 2015-09-08 12:49:21 UTC
We have integrated LibreOffice in out Tool, and we are creating some Shapes programmatically in sdraw.
After a few Shapes (more than 65535) the Shapes are not shown as expected (some are in Back or other, while they should be in Front). 
This is because the ZOrder of the Shapes are not incremented after 65535.

I have wrote a Macro to reproduce it (see end of the Description)

In LibreOffice it is reproducible.
I have tried to reproduce it in LibreOffice, but the program crashed after a couple of time and the macro will not finish.

	Dim shapeSize As new com.sun.star.awt.Size
   	Dim shapePos As new com.sun.star.awt.Point
   	Dim I 
   	Dim shape
    shapeSize.width = 2000
  	shapeSize.height = 3000
  	document = ThisComponent
	drawPage = document.DrawPages(0)
	For I = 1 To 65540 Step 1

		shape = document.createInstance("com.sun.star.drawing.RectangleShape")
		'shape.ZOrder = i
	  	shapePos.X = i
	  	shapePos.Y = i
	 	If shape.ZOrder > 65534 Then
	 		MsgBox shape.ZOrder
	 	End If
	Next I
Comment 1 Buovjaga 2015-09-15 16:01:27 UTC
Confirmed the weirdness in 5.0.1, but was unable to get a backtrace.

Win 7 Pro 64-bit, Version: (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Comment 2 Julien Nabet 2016-07-05 21:56:46 UTC
Part of backtrace:
#0  SdrObject::GetOrdNum (this=0x89ca6f0) at /home/julien/lo/libreoffice/svx/source/svdraw/svdobj.cxx:777
#1  0x00002aaab0d950af in SvxShape::getPropertyValueImpl (this=0x89c8ff0, pProperty=0x4196350, rValue=uno::Any(void))
    at /home/julien/lo/libreoffice/svx/source/unodraw/unoshape.cxx:2576
#2  0x00002aaab0d9d86a in SvxShapeText::getPropertyValueImpl (this=0x89c8ff0, rName="ZOrder", pProperty=0x4196350, rValue=uno::Any(void))
    at /home/julien/lo/libreoffice/svx/source/unodraw/unoshape.cxx:4077
#3  0x00002aaab0d91dc8 in SvxShape::_getPropertyValue (this=0x89c8ff0, PropertyName="ZOrder") at /home/julien/lo/libreoffice/svx/source/unodraw/unoshape.cxx:1744
#4  0x00002aaad3f47292 in SdXShape::getPropertyValue (this=0x89a62b0, PropertyName="ZOrder") at /home/julien/lo/libreoffice/sd/source/ui/unoidl/unoobj.cxx:831
#5  0x00002aaab0d91c60 in SvxShape::getPropertyValue (this=0x89c8ff0, PropertyName="ZOrder") at /home/julien/lo/libreoffice/svx/source/unodraw/unoshape.cxx:1725
#6  0x00002aaaf23e66e3 in (anonymous namespace)::IntrospectionAccessStatic_Impl::getPropertyValueByIndex (this=0x83c8cf0, obj=
  uno::Any("com.sun.star.uno.XInterface": {_vptr.XInterface = 0x89c9028}), nSequenceIndex=40) at /home/julien/lo/libreoffice/stoc/source/inspect/introspection.cxx:571

I'm not sure but it seems to depend on SdrObjList::RecalcObjOrdNums() which depends on SdrObjList::GetObjCount() which corresponds to maList.size();
finally maList is defined as ListType which is typedef std::vector<std::unique_ptr<SdrObjUserData> > ListType;

So might be system constraint.
Comment 3 Armin Le Grand 2016-07-07 10:49:28 UTC
Yes, a limitation due to the old roots of the office. Changed in aw080 (I think), but not yet available...
Comment 4 QA Administrators 2017-09-01 11:18:32 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2019-12-03 14:46:30 UTC Comment hidden (obsolete)
Comment 6 mmaurer 2019-12-04 08:13:53 UTC
Bug is still present

Version: (x64)
Build-ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU-Threads: 8; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded