Created attachment 51683 [details]
Writer document used for test

Confirm with OOo 2.4 RC1 on WinXP, Win98 and OpenSUSE 10.3

I changed OS "Linux" to "All"

-> pl
I did a first rough investigation, using a simple Writer document with a
pushbutton only.
In a debug session limited to the modules I know, I observed:
- method PDFExtOutDevData::SetIsExportFormFields( const sal_Bool
bExportFomtFields ) sets the correct value of the form export flag, according to
the filter interface
- method PDFExtOutDevData::GetIsExportFormFields() never gets called while
exporting the document.
- finally, in method PDFWriterImpl::emitWidgetAnnotations() there is no widget
to export.
Just a wild guess: may be it's application related?
I didn't add the issue to the 2.4 showstopper bugs list because I don't know if
it's related to another one already being investigated.

actually I know of this as issue 86274, but up to now I thought this was
SRC680m245 and up only. I'm currently looking into it.

Even more curious, if I create a new document containing just a button, it
works, but not with the attached sample.

This is even more curious, if I copy the controls from the document to a new one
and export that, it works. If I save the document, close it and open it again,
export to PDF it still works. Just when I end the application, start it again
and export to PDF, it fails.

However the same thing fails the same way in Impress, so I guess this is not
application dependent.

However I think this is certainly a stopper issue

Here is another example - http://community.i-rs.ru/index.php?
action=dlattach;topic=7701.0;attach=5524 .

Philipp,
as mentioned in Russian-language discussion[*] controls are exported until you 
save and close file. Once you open existing file controls would not export.

*http://community.i-rs.ru/index.php/topic,7701.msg49009/topicseen.html#msg49009

Debugging I see that we never reach describePDFControl in
svx/source/form/formpdfexport.cxx in case the document was loaded (we come
though there if exporting a new document however).

Insetad I get asertions on the commandline (I compiled svx/source/form with
debug) saying

Error: File
/export/home/pl93762/vclshowstop14/svx/source/form/fmcontrolbordermanager.cxx,
Line 399: ControlBorderManager::validityChanged: invalid control/peer!
Backtrace: [0] /export/home/pl93762/vclshowsto

I'm a little out of my field of experience in svx and forms, could you please
have a look ?

just confirming what everybody expected: same behavior on Windows

fs->aw: just notifying you ATM. I need to investigate, but my gut feeling is
I'll return to you on the topic ...

note: this is a regression between OOH680m3 and OOH680m4.

namely a regression of issue 82791

Okay, the fix for issue 82791 (resp. issue 83611) triggered a long-standing bug
in our toolkit code - certain controls claimed to be invisible in certain
situations, even if they knew better. Since the drawing routines respect the
visibility of controls with the fix for the above-mentioned issues, and PDF
export unfortunately was such a "certain situation", no controls were exported
anymore.

Thanks a lot.
If only all issues could be handled this fast ...

SBA: Set keyword "regression" (Broken since OOH_m4).

fs-> hi: please verify in CWS formpdfexportfix

Verified in CWS formpdfexportfix = OK

*** Issue 86274 has been marked as a duplicate of this issue. ***

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues