correcting priority (see
http://www.openoffice.org/issues/bug_status.html#priority - sorry,
phill, but we're not talking 'about crashes or loss in functionality
of a complete area)

Phill, I have a problem reproducing this on Windows, with OOo 1.1 Beta
2. Following your instructions, I
* open a new text document
* insert a date control
* set it's drop down property to "yes"
* switch off the design mode
=> the control is automatically filled with the current date
* print the document
=> the default date in the control is automatically printed.

Similar for a combo box bound to an arbitrary Bibliography/biblio column.

What am I doing differently? Do you mind adding a document which shows
the bug?

Created attachment 6512 [details]
Example form that will not print field when dropdown=yes

Created attachment 6513 [details]
PDF print of output when dropdown=no

Created attachment 6514 [details]
PDF print of form when dropdown=yes for selected fields

Created attachment 6515 [details]
Text file to be loaded as datasource "Members"

I've uploaded a small version of the database that needs to be loaded
as a datasource called "Members".  You can then use the Operative form
to see what I mean as far as the fields not printing.  Just in case
that isn't possible there are two prints (using a pdf printer) that
show with (OPS-threedrop) and without (OPS-nodrop) dropdown=yes for
the two fields DOB & Date Graded.

I have tried to workout why this is happening but with no luck.  I can
reproduce it on several independent machines but using this already
exisiting forms.  I have created a form from scratch and it worked as
expected :-(  I'll keep looking to what is making it disappear on this
form and selected others too...

Forgot to rename spreadsheet!  Sheet1 should be renamed to Operatives

Created attachment 6539 [details]
stripped down the bug case

The new attachment is stripped down - it does not bind to a data
source anymore, and contains a reduced number of controls for easier
debugging.

grabbing the issue for myself

set target to OOo 2.0

I have just ran some tests by creating a new form from a blank
document and the fields print okay.  It is pretty much identical to
your stripped down version, only difference is it does print.  I
looked at the content.xml file but they are practically identical... :-(

Created attachment 6664 [details]
similar stripped down file but it prints

I'll try to have a look at this before my vacation - I'd be eager to
fix this for 1.1, because without knowing about the reasons, we can't
be sure if it hits 0.01 or 99 percent of the users/form documents.

the key is the  background color. A drop-down combo box, which has a
background color other than "standard", does not print it's content.

fs->mt: the problem is in ComboBox::Draw: If it's a drop-down box, it
_first_ draws the text (resp.: it lets it's sub-edit draw), and then
does everything else. This "everything else" includes drawing the
background, if necessary - which overwrites the text.
I tried moving the drawing of the text from the beginning of the
method to the end, and this seemed to work well. From my
understanding, this should be a good solution, but there may be side
effects which I do not see. Could you please have a look at this?
Would be really cool if we get this in the 1.1 time frame :)

Frank, once again you've done it!  I'm so impressed with the speed you
manage to solve this crazy issues.  Thanks so much!  P h i l l

I'll check that...

Fixed...

MT->MSC: Please verify and close

set to fixed

verified in CWS vcl12

close, because it's fixed in OOo 1.1 RC

change subcomponent to 'none'