Author Topic: wxSmith bugs with wxTreeListCtrl  (Read 6311 times)

Offline wl_fs

  • Single posting newcomer
  • *
  • Posts: 5
wxSmith bugs with wxTreeListCtrl
« on: July 11, 2015, 06:14:23 am »
Hi!
when I using codeblocks with wxTreeListCtrl, wxSmith generates wrong codes.

dialog based wxSmith program:
include file error: should be wx/treelist.h while wxSmith generates wx/treelistctrl.h in wxXXXMain.h
declear error: there is no wxTreeItemId defined in treelist.h
code error: wxTreeListCtrl with wrong paras, addcolumn, addroot, ... no these functions

I think it may be confounded between wxTreeListCtrl and wxTreeCtrl.

Codeblocks: 13.12 release, 20141206_rev10050_win32 and 20150619_rev10341_win32.
wxWidgets3.0.2, mingw-4.7.1-TDM
MinGW: 4.7.1
« Last Edit: July 11, 2015, 06:17:31 am by wl_fs »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: wxSmith bugs with wxTreeListCtrl
« Reply #1 on: July 11, 2015, 09:25:55 am »
wxTreeListCtrl is new in wxWidgets since wx2.9.3 .
The wxTreeListCtrl used in wxSmith's contrib-section is an older  implemetation/contribution used by C::B created by several authors and not compatible with wx3.

The greatest problem is, that the class is named as the wx3 class and it conflicts in wx3 builds and can lead to a crash.

It has definitely to be removed or renamed for wx3-builds.

We have several scenarios:

C::B build with wx2.8:
used for wx2.8: we can leave it as it is,
used for wx3.0: we need a new version, that has to be auto-disabled when used to create wx2.8-code.
C::B build with wx3.0:
used for wx2.8: existing code can not be used easily because of name-conflicts, what to do? Rename the existing class ?
used for wx3.0: we need a new version, that has to be auto-disabled when used to create wx2.8-code.

I think we need a decision here.
I don't know if wxSmith knows the wx-version it is used for (chosen in the wizard).

My favourite is to remove the existing incompatible wxTreeListCtrl and only use a new one when used for wx3.0.

That's at least the easiest and most clear way, even if it might break old code using the contributed wxTreeListCtrl.
The removal for wx3-builds will definitely come (probably this weekend), because it avoids a crash when closing C::B.

I'm not sure how to fix t his.

Offline wl_fs

  • Single posting newcomer
  • *
  • Posts: 5
Re: wxSmith bugs with wxTreeListCtrl
« Reply #2 on: July 11, 2015, 12:16:48 pm »
Hi!
Thanks for your reply.

I have checked the codes of wxWidgets2.9.2, 2.9.3 and later. I found that only from 2.9.3 that wxTreeListCtrl was present.
But, none of the version has the file name TreeListCtrl. All of them have the name TreeList,
and all the class have the same declaration, and have same basic functions.

I keep my mind that wxSmith just has the bugs with this control.
I hope the new wxSmith version fixing it.

Best regards.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7588
    • My Best Post
Re: wxSmith bugs with wxTreeListCtrl
« Reply #3 on: July 11, 2015, 04:08:20 pm »
wxTreeListCtrl is new in wxWidgets since wx2.9.3 .
The wxTreeListCtrl used in wxSmith's contrib-section is an older  implemetation/contribution used by C::B created by several authors and not compatible with wx3.

The greatest problem is, that the class is named as the wx3 class and it conflicts in wx3 builds and can lead to a crash.

It has definitely to be removed or renamed for wx3-builds.

We have several scenarios:

C::B build with wx2.8:
used for wx2.8: we can leave it as it is,
used for wx3.0: we need a new version, that has to be auto-disabled when used to create wx2.8-code.
C::B build with wx3.0:
used for wx2.8: existing code can not be used easily because of name-conflicts, what to do? Rename the existing class ?
used for wx3.0: we need a new version, that has to be auto-disabled when used to create wx2.8-code.

I think we need a decision here.
I don't know if wxSmith knows the wx-version it is used for (chosen in the wizard).

My favourite is to remove the existing incompatible wxTreeListCtrl and only use a new one when used for wx3.0.

That's at least the easiest and most clear way, even if it might break old code using the contributed wxTreeListCtrl.
The removal for wx3-builds will definitely come (probably this weekend), because it avoids a crash when closing C::B.

I'm not sure how to fix t his.

Upstream at wxcode adds the namespace of wxcode around the class.

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

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: wxSmith bugs with wxTreeListCtrl
« Reply #4 on: July 11, 2015, 06:43:02 pm »
Upstream at wxcode adds the namespace of wxcode around the class.

The problem, that the both implementations of wxTreeListCtrl are not compatible and that makes the implementation in wxSmith (at least) problematic.

For the moment I completely removed it from wx3.0 project-files and autofoo-stuff.

Offline wl_fs

  • Single posting newcomer
  • *
  • Posts: 5
Re: wxSmith bugs with wxTreeListCtrl
« Reply #5 on: July 17, 2015, 04:26:04 pm »
I have read the instructions on the wxWidgets' web about wxTreeListCtrl. It said that it had its own TreeListCtrl since 2.9, and the interfaces were incompatible from the conti one's. Here conti one I thought,  was referenced to wxCode.
Am I right?

If so, I had a suggestion that the new codeblocks version also included the debug version of wxWidgets libary and header files for convenience for most of the mingw + wxWidgets developers.

Thanks for reply.
Best regards.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: wxSmith bugs with wxTreeListCtrl
« Reply #6 on: July 17, 2015, 05:00:36 pm »
If so, I had a suggestion that the new codeblocks version also included the debug version of wxWidgets libary and header files for convenience for most of the mingw + wxWidgets developers.
"debug version of wxWidgets libary"? That's a big library(about 200M or more bigger) if it is a debug version.
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 wl_fs

  • Single posting newcomer
  • *
  • Posts: 5
Re: wxSmith bugs with wxTreeListCtrl
« Reply #7 on: July 24, 2015, 09:57:35 am »
Yes, it is my opinion.
I do not think it is a problem for developer. It may be published as an indepent package.