Author Topic: wxSmith and the Style woes of the future.  (Read 944 times)

Offline ouch

  • Almost regular
  • **
  • Posts: 221
wxSmith and the Style woes of the future.
« on: July 28, 2018, 02:55:43 pm »
The new trunk version of wxWidgets is changing border style names. I know it's not a release version yet but it's been a pain to work with in the editor so I've attached a patch to fix it for those who are using the trunk version of wxwidgets.

For patches fixing version issues should we use an ifdef wall or are you directly comparing the wxwidgets version in a variable someplace?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5055
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: wxSmith and the Style woes of the future.
« Reply #1 on: July 28, 2018, 05:20:17 pm »
Good work!
Hope some wxSmith export would give some advice. ;)
wxSmith should know which wx version does the generated code link to.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6280
    • My Best Post
Re: wxSmith and the Style woes of the future.
« Reply #2 on: July 28, 2018, 05:49:16 pm »
Good work!
Hope some wxSmith export would give some advice. ;)
wxSmith should know which wx version does the generated code link to.

Assuming it only changes to wxBORDER_* it should work with 2.8.12 which has those defines in wx/defs.h

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #3 on: July 28, 2018, 11:29:54 pm »
For patches fixing version issues should we use an ifdef wall or are you directly comparing the wxwidgets version in a variable someplace?
At the moment wxSmith needs to be able to generate valid wx2.8.12 code. C::B uses it and we're still building for wx2.8.
The best option is to generate something that is available in both versions. If not wxCHECK_VERSION macros should be generated.

How do I test this patch if it generates correct code?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #4 on: July 29, 2018, 12:27:20 am »
If 2.8 has the new styles defined then it should work regardless right?

And if that is the case why not change all of them across the entire codeblocks file structure.

This patch does just that. It was done with a program that does blind search and replace. I have went through it and removed nonsense things like log and readme changes.

But this should in theory work on all versions of wxWidgets >= 2.8.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #5 on: July 29, 2018, 06:16:17 am »
So many words, but you've failed to tell me how to test your patch.  :-\

p.s. Also how do you compile your wx, because I've compiled against current wx-master and everything builds fine.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #6 on: July 29, 2018, 06:41:28 am »
It's not that it doesn't compile, it's that you get an assert popup every time an old style is used now. (Except for wxNO_BORDER for some reason)

Testing the patch is easy, before you apply it though. Build codeblocks against the latest trunk of wxwidgets and leave the debug asserts on. (I actually don't touch the settings in setup.h I leave them as default) Go into any codeblocks project with a .wxs layout, click on a control and try to change the border. You will get a bunch of invalid border style assert popups. Your style will also not be applied.

Now apply the patch and rebuild codeblocks, once again go find a project containing a .wxs click on a control and change it's border. The popups will be gone and the control will get the border you selected applied.

The wxsmith generated code/xrc will also have the new style listed instead of the old one as well.

I also believe I saw this popup when certain codeblocks windows get loaded. Although I don't remember which. But if you apply the second patch those will go away too.
« Last Edit: July 29, 2018, 06:44:26 am by ouch »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #7 on: July 29, 2018, 01:32:14 pm »
I can't reproduce this.
What are the compile options of your wx installation?
Are you disabling some compatibility option?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #8 on: July 29, 2018, 02:19:33 pm »
mingw32-make -j6 -f makefile.gcc MONOLITHIC=0 SHARED=0 LDFLAGS="-Wl,--allow-multiple-definition" BUILD=release

my setup.h is attached.

Compiled with:

mingw64: i686-8.1.0-posix-sjlj-rt_v6-rev0 on win 7 pro from a command line batch file.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #9 on: July 29, 2018, 02:53:07 pm »
Hm, probably it is something happening only on windows.
Can you post a backtrace from the assert dialog?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #10 on: July 29, 2018, 03:45:45 pm »
Really? what happens if you click two styles at once?

This is the message I get.

Also, is there even any reason to not update all the style tags?
« Last Edit: July 29, 2018, 03:47:45 pm by ouch »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #11 on: July 29, 2018, 06:37:52 pm »
Nothing. Just works. My gtk2 theme doesn't draw any boarders, so I have no idea what is the effect.

At the moment I'm investigating if this patch would break loading old wxs files. At the moment I think it will. Also xrc loading should be investigated, too.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6280
    • My Best Post
Re: wxSmith and the Style woes of the future.
« Reply #12 on: July 29, 2018, 06:41:31 pm »
@ouch: I have found it is easier to get the changes to the CB Core applied/accepted without changes to the contrib plugins being part of the first patch. Your luck might very from mine.

Edit: Looking more en-depth at the problem; the wxSmith plugin needs fixed before the CB core.
It would be a good idea to add a feature to change wxs files that are opened with wxSmith to use the new names.
Because otherwise it would be a nightmare doing support for newbie users of wxSmith.

Tim S.


« Last Edit: July 29, 2018, 07:26:28 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #13 on: July 29, 2018, 08:23:57 pm »
@ouch: I have found it is easier to get the changes to the CB Core applied/accepted without changes to the contrib plugins being part of the first patch. Your luck might very from mine.
The second patch is easier to apply than the first. I don't think here we need a split.

Edit: Looking more en-depth at the problem; the wxSmith plugin needs fixed before the CB core.
This is true.

It would be a good idea to add a feature to change wxs files that are opened with wxSmith to use the new names.
Because otherwise it would be a nightmare doing support for newbie users of wxSmith.
What do you mean? I think we need a feature which does recreate the source code for all wxs files in a project. This way when wxsmith changes one can update the hole project he/she is working on. Currently wxsmith updates source code only when a file is edited. So the user ends with multiple unrelated changes to the source files.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #14 on: July 30, 2018, 08:52:57 am »
Here is a try to preserve old files. Can someone try if it works and probably do a review if I'm doing the correct thing, because I'm pretty new in the wxsmith code.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6280
    • My Best Post
Re: wxSmith and the Style woes of the future.
« Reply #15 on: July 30, 2018, 12:35:30 pm »
Here is a try to preserve old files. Can someone try if it works and probably do a review if I'm doing the correct thing, because I'm pretty new in the wxsmith code.

Building Win7 wx2.8.12 with your patch; but, I only know a little bit of how to use wxSmith.
I will see if the debug wxs file gets converted correctly. Likely post the changes to get a better opinion on it.
Since, I also do not use debugger very much.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6280
    • My Best Post
Re: wxSmith and the Style woes of the future.
« Reply #16 on: July 30, 2018, 01:16:27 pm »
The wxs file does not get changed/saved; but, the .cpp and .h files are changed.
Is this on purpose or on accident?
Edit: Thinking about it; it does make sense not to change the wxs file till after the next CB Release and maybe even later than that.

Tested on debuggersettingsdlg.wxs

Code: [Select]
src/src/debuggersettingsdlg.cpp | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/src/debuggersettingsdlg.cpp b/src/src/debuggersettingsdlg.cpp
index 68bfe67dd..9fdf9ee6d 100644
--- a/src/src/debuggersettingsdlg.cpp
+++ b/src/src/debuggersettingsdlg.cpp
@@ -3,8 +3,8 @@
 
 #ifndef CB_PRECOMP
  //(*InternalHeadersPCH(DebuggerSettingsDlg)
- #include <wx/string.h>
  #include <wx/intl.h>
+ #include <wx/string.h>
  //*)
 
     #include <wx/choicdlg.h>
@@ -35,18 +35,18 @@ END_EVENT_TABLE()
 DebuggerSettingsDlg::DebuggerSettingsDlg(wxWindow* parent)
 {
  //(*Initialize(DebuggerSettingsDlg)
- wxStaticLine* staticLine;
  wxBoxSizer* headerSizer;
  wxBoxSizer* mainSizer;
- wxStdDialogButtonSizer* stdDialogButtons;
  wxPanel* header;
+ wxStaticLine* staticLine;
+ wxStdDialogButtonSizer* stdDialogButtons;
 
  Create(parent, wxID_ANY, _("Debugger settings"), wxDefaultPosition, wxDefaultSize, wxCAPTION|wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER|wxCLOSE_BOX|wxMAXIMIZE_BOX|wxMINIMIZE_BOX, _T("wxID_ANY"));
  mainSizer = new wxBoxSizer(wxVERTICAL);
- header = new wxPanel(this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxNO_BORDER|wxTRANSPARENT_WINDOW, _T("wxID_ANY"));
+ header = new wxPanel(this, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxBORDER_NONE|wxTRANSPARENT_WINDOW, _T("wxID_ANY"));
  header->SetBackgroundColour(wxColour(0,64,128));
  headerSizer = new wxBoxSizer(wxHORIZONTAL);
- m_activeInfo = new wxStaticText(header, ID_LABEL_ACTIVE_INFO, _("Active debugger config"), wxDefaultPosition, wxDefaultSize, wxNO_BORDER|wxTRANSPARENT_WINDOW, _T("ID_LABEL_ACTIVE_INFO"));
+ m_activeInfo = new wxStaticText(header, ID_LABEL_ACTIVE_INFO, _("Active debugger config"), wxDefaultPosition, wxDefaultSize, wxBORDER_NONE|wxTRANSPARENT_WINDOW, _T("ID_LABEL_ACTIVE_INFO"));
  m_activeInfo->SetForegroundColour(wxColour(255,255,255));
  m_activeInfo->SetBackgroundColour(wxColour(0,64,128));
  wxFont m_activeInfoFont(12,wxFONTFAMILY_DEFAULT,wxFONTSTYLE_NORMAL,wxFONTWEIGHT_BOLD,false,wxEmptyString,wxFONTENCODING_DEFAULT);

Code: [Select]
src/src/debuggersettingsdlg.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/src/debuggersettingsdlg.h b/src/src/debuggersettingsdlg.h
index 9ab0523f7..749848bb4 100644
--- a/src/src/debuggersettingsdlg.h
+++ b/src/src/debuggersettingsdlg.h
@@ -3,9 +3,9 @@
 
 #ifndef CB_PRECOMP
  //(*HeadersPCH(DebuggerSettingsDlg)
- #include <wx/sizer.h>
- #include <wx/panel.h>
  #include "scrollingdialog.h"
+ #include <wx/panel.h>
+ #include <wx/sizer.h>
  #include <wx/stattext.h>
  //*)
 
@@ -40,8 +40,8 @@ class DebuggerSettingsDlg: public wxScrollingDialog
 
  private:
  //(*Declarations(DebuggerSettingsDlg)
- wxTreebook* m_treebook;
  wxStaticText* m_activeInfo;
+ wxTreebook* m_treebook;
  //*)
 
  //(*Identifiers(DebuggerSettingsDlg)

Tim S.
« Last Edit: July 30, 2018, 01:20:51 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #17 on: July 30, 2018, 01:27:29 pm »
The wxs file does not get changed/saved; but, the .cpp and .h files are changed.
Is this on purpose or on accident?
Does the wxs file change if you edit it (unrelated to the style changes)? I think this is sort of expected with the current version and it is accidental.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Miguel Gimenez

  • Multiple posting newcomer
  • *
  • Posts: 94
Re: wxSmith and the Style woes of the future.
« Reply #18 on: July 30, 2018, 01:37:19 pm »
Works for me in W7/64 with wx3.1.1/32, can open WXS files with old style flags and they get converted on the fly in the WXS editor. The CPP and WXS files only change when any property is modified within the editor.

Probably the "upgraded" WXS file will fail to load with an unpatched CB, have not tested this because I executed update31 and lost the unpatched version.

Anyway, the old names are still valid and there is no deprecation notice, just the 'old' comment.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #19 on: July 30, 2018, 03:01:40 pm »
I guess the assert is shown, because we don't prevent two styles related to borders to be set simultaneously. Unfortunately the check seems to be windows only.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #20 on: July 30, 2018, 07:34:40 pm »
I'm at work atm I'll check that patch when I get off. But what happens when you open a wxs file that contains old styles with the patched wxsmith is simply no style gets checked. No error messages or anything. I assume that's because no option matches what is saved and it's just ignored as a result.

edit: Oh, also don't forget wxSmith can save .XRC code too. So it needs to write correctly to the users code, the wxs file and the wxSmith generated xrc file too.

I have an active project that uses XRC files so I'll check that your patch works with those after work too.

Also can linux controls actually have two border styles applied to them? Or should the style selection be changed to like a combobox or something so only one can be selected?
« Last Edit: July 30, 2018, 07:41:21 pm by ouch »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10967
    • Travis build status
Re: wxSmith and the Style woes of the future.
« Reply #21 on: July 30, 2018, 11:04:11 pm »
Doesn't make sense to have, but these are style flags, so the control cannot be changed to a radiobox/button or similar.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ouch

  • Almost regular
  • **
  • Posts: 221
Re: wxSmith and the Style woes of the future.
« Reply #22 on: July 31, 2018, 06:27:08 am »
That patch works for me in that the value gets converted properly on load but doesn't actually get changed on anything until something is changed causing wxSmith to update. once that happens however all files are changed accordingly.