Re: [lmi] [PATCH] More XRC fixes, including wxDatePickerCtrl ones

[Vadim Zeitlin]

On Thu, 16 Apr 2015 23:54:29 +0000 Greg Chicares <address@hidden> wrote:

GC> I realize you're still working on high-DPI enhancements in wx, which is
GC> outside the scope of these patches. But, since I'm looking at it now,
GC> let me describe what I see at 192 DPI. First, these diagnostics appear
GC> on the console:
GC> 
GC> wxSpinCtrl "SolveBeginYear": initial width 20 is too small, at least 34 
pixels needed.
...more similar messages snipped...

 This will soon be (i.e. already is) fixed by my changes XRC: it will now
interpret all pixel values as being in "DPI-independent pixels", i.e. scale
them by DPI/96 factor. As I wrote in my mailing list message at
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/162378 I don't see
any good reason _not_ to do this, as it's impossible to account for the DPI
properly in XRC, unlike in the C++ code, so any pixel values in it should
be scaled.

GC> Some radioboxes seem slightly too narrow, causing text truncation, e.g.:
GC>   "Month by mont" missing final "h"
GC>   "Survive to life expectanc" missing final "y"
GC> But perhaps it's not just a problem with the dimensions of the surrounding
GC> group box, because "( ) Net rate   ( ) Gross rat" is missing a final "e"
GC> even though there's abundant empty space in the right end of the group box.

 This looks like a separate bug in wxMSW, I'll try to debug this a.s.a.p.

GC> Some comboboxes are way too narrow: e.g., "Premium tax state" has only
GC> four horizontal pixels for displaying text, which isn't enough for even
GC> a single character.

 This is also due to the hardcoded 40px size and so will also be fixed by
the XRC changes. FWIW I still don't think it's a good idea to hardcode 40
like this, but at least it will work as well as it ever did after this
change.

GC> On the "Inforce" tab, I was surprised to see that the date-picker controls
GC> are about twice as wide as the text controls with which they're vertically
GC> aligned. Surprised, because they were almost the same width at 96 DPI.
GC> Looking at the source, which I believe has all patches applied (e.g., for
GC> 'skin.xrc', 118 sections differ from HEAD), I see:
GC>                                     
<flag>wxGROW|wxALIGN_CENTER_VERTICAL|wxRIGHT</flag>
GC>                                     <object class="wxTextCtrl" 
name="ContractNumber">
GC>                                         <help>Contract number</help>
GC>                                         <size>80,-1</size>
GC>                                         <value>0</value>
GC>                                     </object>
GC> Didn't you intend to change every occurrence of "<size>80,-1</size>",
GC> at least to remove the "-1"? Have I missed a patch?

 No, you didn't miss a patch. As with "40" above, I do think that it's
wrong to hardcode "80" here, but with the XRC change I keep mentioning it
will become much less wrong, so there is no really compelling reason to
remove it now and I didn't do it.

 As for why wxTextCtrl is more narrow, I admit I have no idea: it should
expand to the width of wxDatePickerCtrl if the latter is wider because of
wxGROW and seems to do it in my testing. I don't see how could this depend
on the DPI, but I'll retest it at high DPI soon.

 Thanks for pointing out these problems!
VZ