This is a sample of the problem i have:
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)?
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.Differences between 2.0 and 2.9, and how to get the same result
-
- CodeLite Curious
- Posts: 6
- Joined: Tue Sep 18, 2018 12:18 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Differences between 2.0 and 2.9, and how to get the same result
You do not have the required permissions to view the files attached to this post.
- eranif
- CodeLite Plugin
- Posts: 6372
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Differences between 2.0 and 2.9, and how to get the same result
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
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
Make sure you have read the HOW TO POST thread
-
- CodeLite Plugin
- Posts: 819
- Joined: Wed Sep 03, 2008 7:26 pm
- Contact:
Re: Differences between 2.0 and 2.9, and how to get the same result
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.
If that's not the answer, perhaps you could attach a minimal workspace that demonstrates the problem.
-
- CodeLite Curious
- Posts: 6
- Joined: Tue Sep 18, 2018 12:18 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Differences between 2.0 and 2.9, and how to get the same result
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:
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:
You do not have the required permissions to view the files attached to this post.
-
- CodeLite Plugin
- Posts: 819
- Joined: Wed Sep 03, 2008 7:26 pm
- Contact:
Re: Differences between 2.0 and 2.9, and how to get the same result
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
.
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
![Smile :)](./images/smilies/icon_e_smile.gif)
-
- CodeLite Curious
- Posts: 6
- Joined: Tue Sep 18, 2018 12:18 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Differences between 2.0 and 2.9, and how to get the same result
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.
Ok![Smile :)](./images/smilies/icon_e_smile.gif)
Perhaps wxCrafter should "warn" about this feature? by turning the "pressed but superseded button" red or something like that?
Thanks again.
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.
LOL
Ok
![Smile :)](./images/smilies/icon_e_smile.gif)
Perhaps wxCrafter should "warn" about this feature? by turning the "pressed but superseded button" red or something like that?
Thanks again.