I have a control, an HTMLViewer in fact, that up to now I’ve just had somewhere in the window. It never actually displays anything visible: I load it up with some html, then print it.
However, just having the Viewer there causes some issues when running under Linux. So, can I move it off screen? I mean, I can, but does that cause any issues if its coordinates place it outside the window?
You can try, but some browser engines won’t draw unless they’re visible to the user.
Don’t know anything about Linux, but could you not put the htmlviewer in a seperate window, then when needed open that window. You may not even need to show it (window.hide).
Like this?
I’m only using the html viewer on macOS but I never had any problems with the off-screen container control.
If the window is resizable, make sure to keep the HTMLViewer away from the visible part of the window.
A nice way to do so is in the Resizing event handler.
Yes. I’ve been using this htmlviewer as a means of laying out and printing an HTML page. Load up the viewer with some HTML, then in the DocumentComplete event, call the print() method. This has worked OK so far on macOS and Windows, and I’ve avoided Linux as I have a number of issues there, as noted in other threads.
I did wonder why I hadn’t just instantiated an HTMLViewer, rather than having an actual control. Perhaps I did once and experienced then what I found today, that I can do that and use Addhandler to give it a DocumentComplete event handler (in which I then use the print() method), but even under macOS the event never fires (whereas with a real control it does).
Perhaps also @Greg_O_Lone 's comment explains why under Linux, even with a real HTMLViewer (not offscreen but only 1px by 1px and at the bottom layer) print() doesn’t work there either.
This may be a better approach, in fact. Requires some thought, possibly while I watch Perry Mason.
I’m with @Sam_Rowlands. I use a separate window with an HTMLViewer to build out print previews with HTML content.
The html viewer needs to be there to load data. And the html viewer shouldn’t be 1x1 pixels because such a small html viewer loads data more slowly.
I have one ticket open where the document complete doesn’t fire. macOS some version.
Mmm. In my case it fires, but only with a real control. It’s with the instantiated version that it doesn’t, even under macOS. Anyway, a separate window sounds better.
Do you really need to PRINT from the htmlviewer??
I generate the html file and then show on htmlviewer and then a button to print to pdf
i use wkhtmltopdf to generate the pdf with the margin, orientation etc by passing over parameter to the wkhtmltopdf
Under macOS at least one can always generate a pdf from the print dialogue.
that is true but not cross platform
Windows 8, 8.1 and all Windows 10 have built in PDF printing capabilities too.
