Apache OpenOffice (AOO) Bugzilla – Issue 42995
"could not create system bitmap"
Last modified: 2013-02-24 21:09:08 UTC
In some special cases I got a "could not create system bitmap" excpetion. The environment to get this is dificult. I could reproduce it if I have : - the attached views.xcu in my registry folder - office is runnig and listen on port 8100 - the navigator window is on the top and have the focus - run an UNO-API test To run the UNO-API-Test start your office with parameter "-accept=socket,host=0,port=8100;urp;" and call inside a solar shell: checkapi -o fwk.ModuleManager While to start the UNO-API test the focus is in a shell, you have to set the focus to the navigator window as soon as possible after you have start the test.
we don't get this fixed for 2.0 anymore. Postponing to 2.0.1
The problem is that no graphics can be created. The number of system graphics (DCs) is already exhausted and the fallback list for window graphics is empty. However, the fallback list for virtual device graphics is not empty and in fact a virdev is about to be created. May be the lists can be shared... ?
note: It is not needed to copy the view.xcu into your folder. It is sufficing to open the stylist window and give it the focus.
sw->cp: this will break the remote connection to the office, since the problem appears on a regular base and afterwards the bridge is unusable, so we should consider to get this done for OOo 2.0 ... the testcase below raises the described exception every time, the only precondition is that the stylist is open and focused to make the failure reliable.
Created attachment 22914 [details] testcase to verify the behaviour
Attached is a testcase that makes the behaviour reproducible on all windows machines I could get my fingers on ;-) To reproduce: 1. open the office and dock the stylist and navigator 2. execute the script "runMe" in the attached zip-archive with the office-installation-path as parameter.
(Probably) fixed in VCL 37. The problem seems to have to do with the reparenting of system windows which was performed much too often, even if the parent did not change. The reparenting is done by destroying the old window and device context and creating new ones. May be this introduced an instability under certain circumstances which is just avoided now most of the time.
ssa->sw: Please verify in VCL37. re-open issue and reassign to sw@openoffice.org
reassign to sw@openoffice.org
reset resolution to FIXED
adjusting target
works as expected in cws_vcl37 => verified
ok in src680_m90 => closed
and now I found the closed button too ;-)