When selecting the print function to print all open files, the printer selection dialogue appears once for each file that's printed, with a "please wait while printing" dialogue appearing in between during printing each file. As such it's completely useless for batch-printing large numbers of files, as the user has to sit and click "ok" on the printer selection dialogue box every time.
Also, a print preview would be a nice feature, as would the option to set scaling for printing :)
Honestly i can't even come to the printing... If i print multiple pages, codeblocks is stuck in some loop and i can not even debug it, because no back trace...
Ok, here is a quick patch that fixes this problem.
drawbacks of this patch:
1) The page count in the print dialog is only for the first editor
2) Each editor is a separate print job
Is it possible to at least disable the controls in the print dialog which doesn't work?
what controls in what dialog?
The controls in the print setup dialog which doesn't work with this patch. You've mentioned that page count doesn't work. I guess there are others which doesn't work.
Just to make a small write up how the printing works at the moment:
Every editor implements its call to the printer. So every print of a editor will display the system print dialog with its own properties...
What does this patch:
It only invokes the system print dialog for the first editor. All follow up editors use the settings from the first editor.
So the page count displayed is only the page count of the first editor. It is not wrong in the sense of totally wrong, it is only displaying the wrong total page count. So all settings made in the print dialog are valid (if you want only print the first page this still works, but only for the first editor)
It is not possible to fix this, without rewriting the whole printing code.... The editors should only fill a print context and the ?project manager? should do the invocation of the system print dialog...
But i think you have a point, and i am working on a patch that disables the page count... This will take some time and i can not test it at linux atm...
Ok, here is a second patch, that disables the page selection in the print dialog....
Have you looked at cbEditorPrintout to see if it could be adjusted to support multiple cbStyleTextControls? The more I look at the proposed solution the more I think it is a hack...
I would apply it if you don't intend to try a more proper fix, because I guess it is an improvement, but not by much...
of course this is a hack...
A proper fix would be to reimplement the whole printing code...
i am looking into it, but i am not really confident to have the motivation to do it...
Ok, i tried to fix this the proper way.
There is still cleanup to do, like naming and codeformating and removing unused code.
I will do this if my approach is approved
Note: with this implementation it should also be possible to implement the print preview functionality without great hassle.
I guess it is OK as an approach in general.
But I don't like our current way of printing editors. I don't like that we modify and then try to restore settings of active editors. In theory scintilla supports multiple views to a single document. So it should be possible to make hidden views and which don't affect the current editors.
Can you try to research if this is possible for a future implementation?
Also I'd be really happy if we don't have any printing related code in the cbEditor class.
Last edit: Teodor Petrov 2018-05-02
I made a quick look over your suggestion with about multiple views, but i can not find anything related about it in the scintilla documentation (beside this: https://www.scintilla.org/ScintillaDoc.html#MultipleViews but this does not explain how to create multiple views, only how to handle the document) . Do you have a link? I am really far away from the whole scintilla component and someone more familiar with it would be much faster...
Yes, these seems to be the apis. I'm not sure how they should be used in wxscintilla context. Also it seems not all are exposed. Another option is to see how we're handling window splittings. Search for m_pControl2 in the cbeditor.cpp file.
Where do you think the print code should live?
In the Editor manager?
Ideally it would be in the codeblocks.exe not in libcodeblocks, because it is not something that plugins can reuse.
I created a branch on my github repo
https://github.com/bluehazzard/codeblocks_sf/tree/fix/ticket/48/3
current implementation:
1) clone the editor view and make all visual changes there
2) remove (comment out) all printing related code from editor class
3) If the printer dialog returns invalid paper use din a4 as default (see ticket #666)
4) Print dialog is only shown once
5) Print dialog shows right page count
6) Print preview is possible
7) No glitches when printing (ok one small blink)
8) Prints fine >900 pages without using any more resources
i am not sure about this... for example if a plugin wants to create automatic reports...
I don't feel to invest more time in this (beside code clean up). I really don't know many people who print their code (and i don't like them ;) ))
Seems ok. Please finish your cleaning, then I'll do one pass on it and I'll commit it.
Ok, made some cleanup and fixed a bug from the previous commit (selected text was not printed)
Also up to date on Github
Works on windows 7, not tested on linux
Last edit: bluehazzard 2018-05-10
i made a rebase and some cleanup and code review for this ticket.
I would like to close this years old issue...
can someone look over it?
I had modifications to the old version of the patch... I had to dig them from my git repo...
Is this still applicable?