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

[Greg Chicares]

On 2015-04-17 23:30, Greg Chicares wrote:
> On 2015-04-10 18:26, Vadim Zeitlin wrote:
[...]
>> 7. Remove explicit sizes from wxDatePickerCtrl in the resources.
[...]
>>    of wxDatePickerCtrl contents. However it also breaks visual alignment of
>>    the controls occupying the same column as wxDatePickerCtrl, so you might
>>    prefer to combine it with the next patch when applying it, I separated
>>    them mostly for ease of reviewing.
> 
> Thanks. Another reason to keep these separate is that it makes it easier
> to track down any possible regression.

And this extra effort paid off immediately, because there's a regression with
HEAD that vanishes if I revert the next patch thus:

  /opt/lmi/data[0]$patch --reverse 
</path/to/0008-Fix-controls-alignment-in-XRC-after-wxDatePickerCtrl.patch

>> 8. Fix controls alignment in XRC after wxDatePickerCtrl size change.
> 
> Committed 20150417T2315Z, revision 6175.
> 
>>    This part finishes the job of the last patch and re-fixes the controls
>>    alignment broken by it. As it uses wxGROW|wxALIGN_CENTER_VERTICAL with
>>    2D sizer elements, it works best with the latest wxWidgets version, but
>>    in practice the difference is unnoticeable under MSW, so you can apply
>>    it even if you don't upgrade your wxWidgets version.
>> 
>>    This patch is not as bad as (6), but I still recommend using word diff
>>    for viewing it as it shows that it mostly replaces wxALIGN_LEFT with
>>    wxGROW, to ensure that all controls have the same size (with wxGROW they
>>    expand to the width of the widest one).

To reproduce: open the 'skin.xrc' tabbed dialog and select the "Inforce" tab.

(1) Text and date controls have grown vertically as well as horizontally, but
their height should not change. The height of such controls on other tabs
does not change even if the dialog is resized.

(2) Previously, all columns were the same width (because the controls they
contained had identical hard-coded widths). Now, the middle column is less
wide than the others. It should be the same not only for symmetry, but also
because its controls need to accept currency amounts at least in the millions
(as do controls in other columns).

(3) Resize the dialog to make it wider. Previously, only the spacing between
columns changed (because control sizes were hard coded). Now, the first two
columns become wider (good), but the third does not (it should, too).

(4) Resize the dialog to make it taller. Unsurprisingly, the text and date
controls' height increases. Surprisingly, the date controls' scroll buttons
don't repaint nicely. They seem to grow, from the top down, a little less
than the date controls' height, with some artifacts below them in the space
that they should grow to fill; this is especially noticeable if you increase
the dialog's height in several small increments. Now reduce the dialog's
height incrementally, and sometimes the scroll buttons don't shrink enough
for their intended height, so the lower scroll button is truncated at the
bottom. Sometimes, one of the scroll buttons has a smaller triangle than
the other. Making the dialog wider and then narrower produces similar
strange effects, sometimes even causing the scroll buttons to disappear.
I think these are just repaint issues, because switching focus away from
lmi and back seems to fix them.

As before, I'm running msw-xp at 192 DPI.

The relevant part of the patch looks like this:

@@ -1257,7 +1257,7 @@
                                     </object>
                                 </object>
                                 <object class="sizeritem">
-                                    
<flag>wxALIGN_LEFT|wxALIGN_CENTER_VERTICAL|wxRIGHT</flag>
+                                    
<flag>wxGROW|wxALIGN_CENTER_VERTICAL|wxRIGHT</flag>
                                     <object class="wxTextCtrl" 
name="ContractNumber">
                                         <help>Contract number</help>
                                         <size>80,-1</size>

and of course a mere 's/wxALIGN_LEFT/wxGROW/' in an XRC file cannot cause
all the anomalies above. (4) has to be a latent wx defect, while (2) and
(3) might be considered latent problems in the original XRC file that have
been unmasked by allowing controls to grow horizontally, though I'm not
sure how to fix them.