I am trying to put the finishing touches on my RichTextCtrl control. I have
run into a problem with Print Preview functionality, demonstrated by the
attached sample application.
Try File > Print Preview 1. You will see that it crashes and burns. Too
bad, as this, as far as I can tell, is how Print Preview is supposed to be
done. (See File > Print, which follows the same pattern and works.)
Restart the application and try File > Print Preview 2. You will see that I
am making some progress. You get a print preview. But when you close it,
you will see that it has altered the RichTextCtrl's formatting, adding
margins that didn't used to be there. I won't be able to do headers and
footers with this, but I can live with that.
I think this can be solved by making a COPY of the RichTextCtrl Buffer for
the Print Preview, but when I try, I get a crash like Print Preview 1
produces. Maybe I'm just got grokking the subtleties of copying the
RichTextBuffer object.
I have to use wxPython 2.8.10.1, at least until the next release of
wxPython, as there is a bug in the RichTextCtrl in later versions of
wxWidgets that Julian has fixed but that has not made it into production
yet. I'm currently working on Windows, though I think the problem occurs on
OS X as well.
Any help would be most welcome.
David
David K. Woods, Ph.D.
Researcher, Transana Lead Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison http://www.transana.org
Restart the application and try File > Print Preview 2. You will see that I
am making some progress. You get a print preview. But when you close it,
you will see that it has altered the RichTextCtrl’s formatting, adding
margins that didn’t used to be there. I won’t be able to do headers and
footers with this, but I can live with that.
Any help would be most welcome.
David
Hi David,
This is not a very satisfying answer, but it seems to fix the issue with Print Preview 2. I noticed that if I manually resized the test window, the original formatting popped back. So I just added binding to EVT_ACTIVATE for that frame and then resize the frame by one point on each side. Calling Layout(), Update(), or Refresh() didn’t do it for me. There should be a way to do this without changing the size but I haven’t found it yet.
> Restart the application and try File > Print Preview 2.
You will see
> that I am making some progress. You get a print preview. But when
> you close it, you will see that it has altered the RichTextCtrl's
> formatting, adding margins that didn't used to be there. I won't be
> able to do headers and footers with this, but I can live with that.
> Any help would be most welcome.
>
> David
Hi David,
This is not a very satisfying answer, but it seems to fix the
issue with Print Preview 2. I noticed that if I manually
resized the test window, the original formatting popped back.
So I just added binding to EVT_ACTIVATE for that frame and
then resize the frame by one point on each side. Calling
Layout(), Update(), or Refresh() didn't do it for me. There
should be a way to do this without changing the size but I
haven't found it yet.
Hi Che,
Well, it does work, even if it's not exactly beautiful. Thanks for the
suggestion. I'll use it (if it works in the multi-page document case, which
is really why this behavior is problematic) if I can't find a better
solution.
> > Restart the application and try File > Print Preview 2.
> You will see
> > that I am making some progress. You get a print preview.
But when
> > you close it, you will see that it has altered the RichTextCtrl's
> > formatting, adding margins that didn't used to be there.
I won't be
> > able to do headers and footers with this, but I can live
with that.
>
> > Any help would be most welcome.
> >
> > David
>
> Hi David,
>
> This is not a very satisfying answer, but it seems to fix the issue
> with Print Preview 2. I noticed that if I manually resized
the test
> window, the original formatting popped back. So I just
added binding
> to EVT_ACTIVATE for that frame and then resize the frame by
one point
> on each side. Calling Layout(), Update(), or Refresh()
didn't do it
> for me. There should be a way to do this without changing the size
> but I haven't found it yet.
Hi Che,
Well, it does work, even if it's not exactly beautiful.
Thanks for the suggestion. I'll use it (if it works in the
multi-page document case, which is really why this behavior
is problematic) if I can't find a better solution.
I just tried a multi-page document and I believe it works.
The reason why this lame solution works is unknown to me
(although I feel like I should know) but I suspect Robin will know.
I implemented a variation of this in my app, and it works perfectly with
multi-page documents.
However, I've discovered another, very similar problem. Print Preview
doesn't ruin the formatting any more, but I've added a bit more formatting,
and have found that PRINTING from the Print Preview spoils the formatting.
I've attached the modified sample app.
I’ve been playing with this for a while now and can’t make any progress. What I really can’t understand is that I tried and failed at another workaround: capturing the XML from the original text right after it was created and then in the OnActivate method (after the initial activation of the frame) loading it back in, so that when it returned from the print preview it would be the same text with the same indents. But I couldn’t get that to work (not very familiar with how to do that anyway; perhaps you could).
Just to prove this approach might work, I also tried reloading the buffer XML into the txtCtrl via a menu selection (to take the activation of the frame out of the logic), and couldn’t get that to work either. I just get an “XML Parsing Error: ‘no element found’ at line 1” Yet if I print out the XML it contains all the same indents, and so this should work. Could it be related to the problem that this person had (with wxRuby version, but I think that is just a Ruby wrapper for wxWidgets)?:
I'm afraid that all I can suggest at this point is to disable or remove the print button from the preview frame.
I'm not sure how it could make the kind of difference you are seeing but I notice that the C++ sample creates a single wxRichTextPrinting object when the app is created, and uses the same instance for all of the print operations. I also notice that the sample is passing the RTC's buffer object to PrintBuffer() and PreviewBuffer() without making a copy of it, so if that is the source of the problem I'm surprised that it hasn't been discovered before.
···
On 2/25/11 10:56 AM, David wrote:
However, I've discovered another, very similar problem. Print Preview
doesn't ruin the formatting any more, but I've added a bit more formatting,
and have found that PRINTING from the Print Preview spoils the formatting.
I've attached the modified sample app.
> However, I've discovered another, very similar problem.
Print Preview
> doesn't ruin the formatting any more, but I've added a bit more
> formatting, and have found that PRINTING from the Print
Preview spoils
> the formatting. I've attached the modified sample app.
I'm afraid that all I can suggest at this point is to disable
or remove
the print button from the preview frame.
I'm not sure how it could make the kind of difference you are
seeing but
I notice that the C++ sample creates a single
wxRichTextPrinting object
when the app is created, and uses the same instance for all
of the print
operations. I also notice that the sample is passing the
RTC's buffer
object to PrintBuffer() and PreviewBuffer() without making a
copy of it,
so if that is the source of the problem I'm surprised that it hasn't
been discovered before.
Thanks for the hint. I am implementing a variation on your theme of
disabling the button. I can hijack the wx.EVT_BUTTON event from the
wx.PreviewFrame's Print button, binding it to MY print method, and that
avoids the whole problem. That gives me work-arounds for all the problems
I've run into except for the inability to add headers and footers to the
workaround print preview mechanism.
FYI, the whole set of RichTextPrinting PreviewBuffer problems occur in
wxPython 2.8.11.0 as well as the older version of wxPython I discovered them
on. And further, I tried to recreate this set of problems using C and
wxWidgets 2.8.11 but could not do it. That is, all print previewing and
printing worked as expected, with proper formatting, without crashing, and
without disrupting the originating wx.RichTextCtrl buffer. I *think* these
problems are introduced in wxPython, and don't come from wxWidgets.
Thanks, Che, Micah, and Robin, for your help.
David
David K. Woods, Ph.D.
Researcher, Transana Lead Developer
Wisconsin Center for Education Research
University of Wisconsin, Madison http://www.transana.org