i inserted a list box and linked values from database (.odb) i exported to pdf and no values wasn't shown i tried more times and found the problem -> the design mode need to be switched off before exporting to pdf, than it works fine in my opinion there should be a warning shown or the design mode should be switch off automatically by exporting
Created attachment 119113 [details] the form with a list box
Created attachment 119114 [details] the pdf without values
Please attach example document + database so we can test quickly. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the files.
Created attachment 119189 [details] the database pdf.odb
Created attachment 119190 [details] the writer document pdf.odt
database and document for testing attached
Ok, I confirm and change to enhancement. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
<shrug> PDF export does/should do the same as "Print". I'm rather of the opinion that it should do what is on the screen now, so if no data on screen (because in form design mode), then no data in print & PDF.
In my opinion it's frustrated for a newbie who contact Libreoffice in the first time - i spend a lot of time for to find the issue and i had created a successfully form -> you need to be think for the dumbest assumable user's of the world - not everybody has a patience like me -> the most one will take a look - tried 3 times and search for alternative which works instantly i think
let met suggest as easyHack. But Ilmari, feel free to set/take the proper procedure for this :) thanks - Cor
I think this needs some UX advice on how to warn the user when this happens or just take the approach @Lionel suggested.
We have a couple of options: a) Confirmation box when a dialog is printed in design mode (request) b) Print an empty dialog (comment 8, no action required) c) Disable printing in design mode d) Automatically switching to edit mode on print (and back after) e) WYSIWYP - print what the user is seeing Option a) doesn't solve the issue, c) leads to confusion why a function is disabled, d) contains implementation effort, and e) depends on the cause of this issue. Opinions? (In reply to Shinnok from comment #11) > I think this needs some UX advice... In that case I remove the keywords "easyHack, filter:pdf, needsDevEval"
(In reply to Heiko Tietze from comment #12) > a) Confirmation box when a dialog is printed in design mode (request) > ... > Option a) doesn't solve the issue, When the confirmation box just says: "Mind, because the form is in design mode, no data related to controls will be saved" it dóes save the problem, no?
(In reply to Cor Nouws from comment #13) > When the confirmation box just says: "Mind, because the form is in design > mode, no data related to controls will be saved" it dóes save the problem, > no? The use case is printing a form. Not to understand why it is not possible. So a) 'solves' a follow-up problem, which is to give feedback.
(In reply to Heiko Tietze from comment #14) > The use case is printing a form. Not to understand why it is not possible. > So a) 'solves' a follow-up problem, which is to give feedback. You can create PDF forms with data in some of the controls to choose from. But if you create the PDF while the form is in design mode, there is no data added to the controls in the PDF ;)
We discussed the topic in the design meeting. The use case to export the design is very unlikely. So we suggest to always switch into edit mode before exporting to PDF (and ideally back when done).