The 17 May 2012 build (7966) is out.

[Grom]

I would spend time on wxSmith. Basically Borland-Embarcadero idea can be implemented here. The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith. + Higher level of automation in wxSmith can be achieved with python script (it will give more automatic menus and tool bars).

[MortenMacFly]

The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith.

I don't quite get what exactly you mean, but integrating new UI controls is rather easy already in wxSmith.

What's missing is IMHO an inheritance strategy for UI controls that derive from others. Here, sometimes you won't see the parent's event handlers. If you have some spare time,  concept / implementation for this would be really beneficial.

[MortenMacFly]

Hopefully this time nothing is missing in the patch (except the adjusted makefile.am ...).

Tested and works fine here, feel free to commit from my side (including the makefile.am update from my other post).

[hooluupog]

Codeblocks still freezed when debugging application with large data (for example, vector with 10,000 elements).Yep,"set print elements" can avoid this problem.However,visual studio can show all of the elements imediately when debugging. I don't know how they managed to do that.

[MortenMacFly]

I don't know how they managed to do that.

Well first of all they use a completely different debugger principle...

[afb]

- Mac OS X: (10.4 and up, ppc and i386 - no x86_64 with wxMac)
  http://prdownload.berlios.de/codeblocks/CB_20120517_rev7966_mac2812.zip

More like "yearly" than "nightly", but anyway.

[ollydbg]

I don't know how they managed to do that.

Well first of all they use a completely different debugger principle...

@Morten
What does this sentence mean? I want to hear more words about this.

[MortenMacFly]

What does this sentence mean?

Simply that the VC debugger is completely different from GDB.

[hooluupog]

Is there any way to solve the problem? It is so annoying when debugging.

[oBFusCATed]

Is there any way to solve the problem? It is so annoying when debugging.

At the moment no... use set print elements to a small value... sorry...

[Grom]

Just open Delphi or Lazarus component project. They have special file with registration of control in controls palette. I would tell that Delphi is some-kind of standard of visual development.

The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith.

I don't quite get what exactly you mean, but integrating new UI controls is rather easy already in wxSmith.

What's missing is IMHO an inheritance strategy for UI controls that derive from others. Here, sometimes you won't see the parent's event handlers. If you have some spare time,  concept / implementation for this would be really beneficial.

[oBFusCATed]

Delphi is just dead, something from the past... 

[Ceniza]

Delphi is just dead, something from the past... 

I wish! Delphi has been catching up since the 2009 version, although they care more about adding features than properly testing and fixing bugs. You can even do 64 bits, MacOS X and iOS development with the latest version (some of those using FireMonkey, which introduces hardware acceleration and some other things).

What allows languages like Object Pascal (Delphi), .NET (C#, ...) and a few others to be nicely and easily used for RAD, visual design and so on is extended support for type introspection through RTTI. In that area C++ is rather... poor. It's true it always comes with a price in terms of overhead and code bloat, but it allows for rather nice stuff to be more easily created and self contained. There's a big chance C++ will not support such a thing to that extent, so solutions like those provided by wxSmith will have to stay the norm. No matter how hard you try to make your design as good as possible for it, it's never good enough for some.

[hooluupog]

Is there any way to solve the problem? It is so annoying when debugging.

At the moment no... use set print elements to a small value... sorry...

Hi, I tried debugging again within gdb 7.3(python enabled) command environment  and set print elements 0 to let it print all of the elements ,it works well and gives me a very quick response. But it freezed or ran so slowly when debugging in codeblocks. Seems it is not gdb's flaw.

[ollydbg]

Is there any way to solve the problem? It is so annoying when debugging.

At the moment no... use set print elements to a small value... sorry...

Hi, I tried debugging again within gdb 7.3(python enabled) command environment  and set print elements 0 to let it print all of the elements ,it works well and gives me a very quick response. But it freezed or ran so slowly when debugging in codeblocks. Seems it is not gdb's flaw.

Hi, Hooluupog. I do not think so.

Codeblocks just serves as a front end of gdb, so the most situation is: gdb freeze cause codeblocks freeze.

I believe you can give use the log of both gdb (under Windows Shell) and the gdb log (under Codeblocks Debugger panel), then we can see whether you are true.