set target

.

this is a porting issue which has probably to get fixed in vcl
I just call Window::SnapShot() to get the bitmap

Is this issue still valid ?

Just checked in 680m7 Build:9044
PPC Mac OS X 10.3
X11 1.0 - XFree86 4.3.0
This issue is still valid

To test it, use the TestTool,
in .testtoolrc insert:
[Screenshot]
Current=1
All=1

and run a short update test e.g qa/qatesttool/math/m_updt.bas
after that you have some screenshots in the user directory.
for every screenshot:


the path is shown in the resultfile of the TestTool application

I have tested it here with OOF680_m6 build and screenshots work as usual.

What program have you used to view them? I remember I have had the same problem on SUSE Linux with 
xv - it opened some bitmaps as completely black even if e.g. display displayed them correctly.

WORKSFORME?

Just checked on MacOS X Tiger - still black;
Will attach the file.
Looked at with OOo and 'Preview'
OOo OOF680m2

Created attachment 42932 [details]
black picture?

Shaun, James: can you give us some .bmp files from your testtool?

I doubt this is fixable without changing the way the screenshots are aquired
completely.
I think this is a problem with Apple's X11. Even xmag doesn't work there (but is
shipped with it) - xmags only shows black frames as well...

I have taken some screenshots and here we are:

http://tmp.janik.cz/OpenOffice.org/MacOSX/testtool-screenshots/

Some of them are really black - why?

Any ideas?

I have collected even more screenshots at

http://tmp.janik.cz/OpenOffice.org/MacOSX/testtool-screenshots-2/

Sometimes, some are black, without a known reason, regardingless on which
platform it ran.
One issue that is workarounded, was a timing issue: the screenshot was taken,
before the dialog was completely drawn - which resultet in a 'snow' picture.
I couldn't reproduce the 'sometimes black' pictures - they were never the same.
So I lived with about 3% of all pictures are black on the others platforms - not
Mac.

Now that I see, that some work on Mac, I will run through the complete
application, to also get some good ones - and see if I get the same black as you.

On my system, I see the same black images for every run of the testtool. The same applies to correct runs.

To sum up, when running firstandtopten, the following dialogs are black:

HID_PASSWD 33071
HID_OPTIONS_DICT_NEW 33814
HID_OPTIONS_DICT_EDIT 33815
HID_DLG_NAME 33818
HID_LNGDLG_NUM_PREBREAK 34168
HID_EDIT_MODULES 34169
HID_OPTIONS_JAVA_PARAMETER 39998
HID_OPTIONS_JAVA_CLASSPATH 39999
HID_XMLSEC_TP_SECLEVEL 43069
HID_XMLSEC_TP_TRUSTSOURCES 43070
HID_MM_TESTACCOUNTSETTINGS 54979
HID_MM_SERVERAUTHENTICATION 54993
svx:ModalDialog:DLG_DOCUMENTLINK 1346109440

Do you see any common thing in them?

Many of them are connected with security features - passwords, server authentication, trust sources, ...

I'm out of ideas now.

I've starting doing the tests with screenshots.
http://smsm1.selfip.info/~oootestsmsm1/ooo/testtoolresults/screenshots1/writer/33358.bmp
is one of a few that does work.

Most of the screenshots that I have looked at are just black.

For more screenshots see:
http://smsm1.selfip.info/~oootestsmsm1/ooo/testtoolresults/screenshots1/

@pjanik:

Testtool crashed with a error 5.  Interesting that this happened as this is an
error that I am not familiar with.

Here is the full text of the error message from xterm:

soffice.bin(6998,0x3003c00) malloc: *** error for object 0x5212620: incorrect
checksum for freed object - object was probably modified after being freed,
break at szone_error to debug
soffice.bin(6998,0x3003c00) malloc: *** set a breakpoint in szone_error to debug


Fatal exception: Signal 5
Please turn on Enable Crash Reporting and
Automatic Display of Crashlogs in the Console application
/Applications/OpenOffice.org 2.2.app/Contents/MacOS/program/soffice: line 236: 
6998 Abort trap              "$sd_prog/$sd_binary" "$@"

Looks like a malloc error, but I could be wrong.
BTW, this is OOF680_m6.

James McKenzie

jjmckenzie: I have by chance seen the malloc error that you mention (or
something  very similar). Maybe it was time I started storing the log of the
output from testtool instead of me just seeing a few snippets of it.

1. please don't make a discussion list of this issue ;-) 1 problem per issue only
-> malloc please go to a new issue
thx.

2. I did a run of screenshots with linux, there I don't get any  black ones
right now :-)

3. Will do a run on mac, and look if i can see a reason.

Further investigating;

I choose the Dialogs in writer options:
Writer->Tools->Options->Language Settings->
A: The dialog itself: name in testtool is 'TabLinguistik' ID: 33812
B: pressing upper button 'Edit' -> Dialog: Edit Modules : testtool name:
'ModuleBearbeiten' ID: 34169

Using A: TabLinguistik.SnapShot("/some/path/A.bmp") - picture is dialog
Doing it for B results in black picture;

xmag doesn't count, since it always produces black ;-)
I took the xwd screenshot tool for A and B and both screenshots are ok
(start xwd -out /some/path/A.xwd And then convert A.xwd A.png)

->PL: Do you have an Idea, why the ScreenShot command doesn't work on some
dialogs on MacOS X - X11?
      (See entry from GH from 7.4.2006 for how testtool uses the .ScreenShot
command.)

can anyone check whether cranking up the timeout in
gsl/vcl/unx/source/window/salframe.cxx in the :Snapshot method (say from 50 ms
as is to 500 ms) fixes the problem ? That timeout always was a tad arbitrary.

I added one zero to 5000... there but the same set of screenshots is black again.

I tried some ideas to narrow this down with tbo, but sadly to no avail.

1. It does not help to call XSync repeatedly to force the Xserver to send us
still missing events.
2. Currently the snapshot is being done from the root window (to snapshot the
window manager's decoration, too). It does not help to get the image from the
dialog window itself instead.
3. Changing the region from which the image is taken does not help either.

Always the Xserver sends us a completely black image in XGetImage

Really astonishing is the fact, that this reproducibly does not work for some
dialogs while it works for most.

Sorry, currently I'm fresh out of ideas.

Since the problem only occured on Mac/X11 which is now dead, I think we can
close this issue.

closing