User forums > Nightly builds
The 17 May 2012 build (7966) is out.
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.
--- Quote from: MortenMacFly on May 22, 2012, 08:20:53 pm ---
--- Quote from: Grom on May 22, 2012, 06:13:14 pm ---The wxWidgets component can have some class with list of all control properties to have an easy integration to the wxSmith.
--- End quote ---
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.
--- End quote ---
oBFusCATed:
Delphi is just dead, something from the past... ;D
Ceniza:
--- Quote from: oBFusCATed on May 29, 2012, 06:37:15 pm ---Delphi is just dead, something from the past... ;D
--- End quote ---
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:
--- Quote from: oBFusCATed on May 28, 2012, 06:59:07 pm ---
--- Quote from: hooluupog on May 28, 2012, 06:55:37 pm ---Is there any way to solve the problem? ??? It is so annoying when debugging.
--- End quote ---
At the moment no... use set print elements to a small value... sorry...
--- End quote ---
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:
--- Quote from: hooluupog on May 30, 2012, 05:53:11 am ---
--- Quote from: oBFusCATed on May 28, 2012, 06:59:07 pm ---
--- Quote from: hooluupog on May 28, 2012, 06:55:37 pm ---Is there any way to solve the problem? ??? It is so annoying when debugging.
--- End quote ---
At the moment no... use set print elements to a small value... sorry...
--- End quote ---
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.
--- End quote ---
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. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version