Differences between 2.0 and 2.9, and how to get the same result

[Parduz]

This is a sample of the problem i have:

differences.png

I've build the two project (in wxCrafter 2.0 and 2.9) in the same exact way, but as you can see i obtain two different results.
What i want is what i see in 2.0 (i have a very big project already developed with that version).

Why there's differences in the layout? And, in the case that what is right is what version 2.9 do, how can i obtain the same result as before (so, buttons extending to all the available space)?

[eranif]

Any layout differences are coming from wxWidgets not from wxCrafter.
It's probably the wxWidgets version that wxCrafter is built against (the latest version is built with version 3.1, while I can't really remember which version it was using in 2.0

This only means that once you upgrade your wxWidgets version to 3.1 or later, you will see the same result as shown in wxCrafter

[DavidGH]

FWIW, I just checked here (debian linux, wx3.1.2) and buttons expanded as you want. It would be worth checking the buttons' sizer flags, making sure that they all have wxEXPAND; and the flexgridsizer's 'Growable columns' and 'Growable rows' fields say '0,1' and '0,1,2'.

If that's not the answer, perhaps you could attach a minimal workspace that demonstrates the problem.

[Parduz]

Ok, the problem in 2.9 (on Windows 7) happens only when the "Alignement Buttons" are engaged.
If i don't use them, things are identical, otherwise they act differently in the various combinations.
Is this a Codelite or wxWidgets bug?

Anyway, here's the two projects:

[DavidGH]

I get the same (wrong) result from both wxcps. That's because I'm using wx3.1, not wx2.8.

One of the changes in wx3 was to try to prevent people writing illogical combinations of sizer flags. The commonest example seems to be, in a vertical boxsizer, setting both wxEXPAND and wxALIGN_CENTRE_HORIZONTAL (if the control is fully expanded horizontally, there's nowhere to centre). In a debug build, trying to do that and several similar things will fire an assert; I've spent many happy hours fixing such asserts in CodeLite itself. Recent wxCrafter versions try to prevent you from going wrong in this way (and the latest, unreleased, version does so more successfully).

So your previous wx2.8 setup was letting this problem go, implementing wxEXPAND and ignoring wxALIGN_CENTRE_HORIZONTAL etc. It seems that wx3 is choosing to implement the alignment and ignore the expand/proportion.

So it's "not a bug, it's a feature". I'm glad you spotted the solution .

[Parduz]

Oh.... thanks for the explanation

I'm not sure i like the "solution" to what seems to me to be a "non-problem".... anyway, we can't do anything about it, so ok.

So it's "not a bug, it's a feature".

LOL
Ok
Perhaps wxCrafter should "warn" about this feature? by turning the "pressed but superseded button" red or something like that?


Thanks again.