Re: [lmi] Anomalies with print preview

[Vadim Zeitlin]

On Fri, 24 Jul 2009 22:28:16 +0000 Greg Chicares <address@hidden> wrote:

GC> Using RC6:
GC>   ftp://ftp.wxwidgets.org/pub/2.9.0-RC6/wxWidgets-2.9.0-RC6.tar.bz2
GC> and lmi HEAD as of 20090724T1414Z or later, I see the unexpected
GC> behaviors described below.

 Hello,

 Thanks for testing this, unfortunately it's very unlikely that anything
important changes any more before the final 2.9.0 release as we really,
really want to get it out of the door. So any fixes will have to wait for
2.9.1...

GC> To reproduce, start lmi, then:
GC>   File | New | MEC testing
GC>   tab to "Comments" field and type about a hundred characters
GC>     (I pasted "1234567890" ten times)
GC>     [purpose: to make it too wide for landscape printing]
GC>   click Ok
GC>   File | Print preview
GC> 
GC> (1) This may be lmi-specific, but it baffles me: the icon in the
GC> msw-xp taskbar appears to lose its top row and left column. They
GC> should be black pixels, same as the bottom row and right column.
GC> Instead, while the print preview is active, they're white; dismiss
GC> the preview, and they turn black again. I don't see anything in
GC> DocManagerEx::UponPreview() (in 'docmanager_ex.cpp') that would
GC> cause this.

 That's an amazing bug. I don't know how did you manage to notice it (I
never would have and I think that I usually do pay attention to details).
Luckily fixing it was much simpler than finding it: this was due to the
fact that print preview frame only copied one parent frame icon, which
turned out to be the bigger (32*32) one, and so the small (16*16) icon
shown in the taskbar for it was the one created by scaling the larger one
down and half of the border was lost in the result.

 So this trivial patch will fix it:

--- a/src/common/prntbase.cpp
+++ b/src/common/prntbase.cpp
@@ -1271,7 +1271,7 @@ wxFrame(parent, wxID_ANY, title, pos, size, style, name)
 #ifdef __WXMSW__
     wxFrame* topFrame = wxDynamicCast(wxTheApp->GetTopWindow(), wxFrame);
     if (topFrame)
-        SetIcon(topFrame->GetIcon());
+        SetIcons(topFrame->GetIcons());
 #endif
 }

(I'll commit it to svn soon and could backport it to 2.9.0 if you think
it's worth doing it).

GC> Anyway, this dialog appears:
GC> 
GC> | The document "Printout" doesn't fit on the page horizontally and will be 
truncated if printed.
GC> |
GC> | Would you like to proceed with printing it nevertheless?
GC> |
GC> | If possible, try changing the layout parameters to make the printout more 
narrow
GC> 
GC> (2) Could a period be added at the end of the last sentence, for
GC> consistency?

 Yes, certainly, thanks for noticing that it was missing, this wasn't
intentional. Fixed now in trunk and this, of course, could be back ported
to 2.9.0 too if you think it's worth doing it.
 
GC> (3) I anticipated that pressing Esc on this dialog would trigger
GC> the "Cancel" button, but it doesn't.

 Good point, I didn't think about it when using a Yes/No dialog. I should
have used Ok/Cancel one instead -- done now.

GC> (4) The "Cancel" button has an accelerator (alt-C); isn't it usual
GC> for it to have none on msw (except, implicitly, Esc)?

 Good point as well, fixed too by simply not using any special label for it
-- now that we use Ok/Cancel dialog we can just leave the default one.
Although I also modified wxGetStockLabel() to return "Cancel" instead of
"&Cancel" to avoid having the same problem elsewhere in the future. And I
also made it possible to use wxID_PRINT with it so that we could avoid
duplicating its label here.


GC> (5) "Print" appears to have the same effect as "Cancel". I assume
GC> that "Print" here should mean "proceed nevertheless", so I had
GC> anticipated that I'd see a truncated preview. Instead, I see a
GC> blank preview rectangle, and "Page 1 of 999" on the statusbar.
GC> 
GC> (6) Shouldn't "Cancel" close the print preview (as though its
GC> "Close" button were pressed), instead of leaving the user in a
GC> blank preview where I suppose he can't do anything useful except
GC> press "Close" himself?

 These are real problems and both stem from the fact that I completely
failed to take preview into account when adding this "fit checking" code.
The dialog does work as you'd expect when you attempt to actually print but
it's indeed totally broken when previewing. I'll need to think more about
how to fix this better but it will probably require some deeper changes to
wx printing code.

 Thanks once again for finding all these bugs!
VZ