11
Development / Re: Thinking about a wxSmith Clone Dialog Feature
« Last post by Miguel Gimenez on May 30, 2024, 04:32:53 pm »You can look how wxSmith does it in the wxSmith->Add wxDialog menu.
News:
The new Release 20.03 is out! You can download binaries for Windows and many major Linux distros here .
Recent Posts
12
Development / Thinking about a wxSmith Clone Dialog Feature
« Last post by tigerbeard on May 30, 2024, 02:59:21 pm »I'd love to have a wxSmith "Clone Dialog" function. Because very often it would be faster to remove unused stuff from an existing dialog than to create a new one from scratch.
Currently I am working in a project with a lot of dialogs so there would be plenty of choice for re-use. So I was thinking about how that could be done. Basic steps would be:
* Read from CBP file: CPP, H, WXS filenames for a given "OldClassName"
* Get a new "NewClassName" from User via dialog
* clone the project CPP and H and WXS file of the old dialog
* search and replace the OldClassName with NewClassName in the CPP, H, WXS files.
* add a new line in the CPB file's <wxsmith> section with the WXS, CPP, H, Classname.
Then somehow make CB be aware of the new files and wxSmith of the new WXS file to reload the Resource window list.
Probably not as simple as it sounds? Is that missing something?
I figured out how to add a menu items to a wxSmith tree. The next problem is to read and write a given line from/to the CBP file, but I could not figure that out yet. Any ideas?
Currently I am working in a project with a lot of dialogs so there would be plenty of choice for re-use. So I was thinking about how that could be done. Basic steps would be:
* Read from CBP file: CPP, H, WXS filenames for a given "OldClassName"
* Get a new "NewClassName" from User via dialog
* clone the project CPP and H and WXS file of the old dialog
* search and replace the OldClassName with NewClassName in the CPP, H, WXS files.
* add a new line in the CPB file's <wxsmith> section with the WXS, CPP, H, Classname.
Then somehow make CB be aware of the new files and wxSmith of the new WXS file to reload the Resource window list.
Probably not as simple as it sounds? Is that missing something?
I figured out how to add a menu items to a wxSmith tree. The next problem is to read and write a given line from/to the CBP file, but I could not figure that out yet. Any ideas?
13
Development / Re: new feature of wxSmith in r13522
« Last post by tigerbeard on May 30, 2024, 01:44:41 pm »Very good. Thanks for the info.
I happen to be working a lot with wxSmith these days and I really love it.
I happen to be working a lot with wxSmith these days and I really love it.
14
General (but related to Code::Blocks) / Re: The default code not appearing in .h files
« Last post by Miguel Gimenez on May 30, 2024, 12:25:48 pm »Disable the plugin and check again...
15
Using Code::Blocks / Re: alternative GDB issue
« Last post by nenin on May 30, 2024, 09:13:25 am »For me main surprise was that C::B abandoned default gdb configuration and selected "nix64". It is good feature- manual selection of the actuald debugger- but when user do it with purpose. I did not do it, and I`m afraid that there is kind of "slow" corruption of the default.conf
I`m using ssbssa gdb from time to time, when update of the gdb in mingw distribution is delayed. It is solid stuff.
I`m using ssbssa gdb from time to time, when update of the gdb in mingw distribution is delayed. It is solid stuff.
16
General (but related to Code::Blocks) / The default code not appearing in .h files
« Last post by gregorycollins on May 30, 2024, 06:34:09 am »Hello,
I downloaded a recent nightly build, but there is an issue with default code:. The default code will appear in .cpp files, but not in .h files.merge fruit I like the automatic header file guard #ifndef FOO_H_INCLUDED... Could it be that the default code is over-written by this?
Thanks in advance!
I downloaded a recent nightly build, but there is an issue with default code:. The default code will appear in .cpp files, but not in .h files.merge fruit I like the automatic header file guard #ifndef FOO_H_INCLUDED... Could it be that the default code is over-written by this?
Thanks in advance!
17
Using Code::Blocks / Re: alternative GDB issue
« Last post by ollydbg on May 29, 2024, 02:24:02 pm »Grad to see you have solved your problem.
I use this GDB https://github.com//ssbssa for a long time. I think this GDB is better than the Msys2's GDB.
I use this GDB https://github.com//ssbssa for a long time. I think this GDB is better than the Msys2's GDB.
18
Help / Re: some of my workspaces don't have "other" files folder
« Last post by Miguel Gimenez on May 29, 2024, 11:05:22 am »Spam reported to moderator.
19
Help / Re: some of my workspaces don't have "other" files folder
« Last post by otionwazzack on May 29, 2024, 09:43:29 am »When these files aren't really included in the application the project is creating, I have begun unchecking those boxes lately. They are either byproducts of the ongoing activity or just helpful in some manner to the endeavor.
geometry dash
geometry dash
20
Using Code::Blocks / alternative GDB issue
« Last post by nenin on May 29, 2024, 09:22:56 am »I tried fresh gdb 14 from https://github.com//ssbssa
I configured it as "gdb14-64" (see attach 1 ) and assigned it to the toolchain (see attach 1), replacing native gdb form this toolchain, "nix64" (see attach 1).
However, old "nix64" gdb is jumping out when I`m trying to debug (see attach 1). In default.conf all looks ok (attach 2), when I hacked "nix64" profile to use ssbssa gdb, it worked. Looks like somewhere in depth of the C::B old profile, "nix64", is not replaced with new one "gdb14-64".
"So it goes" (с)
Update: Problem was resolved according to https://forums.codeblocks.org/index.php/topic,22724.msg154381.html#msg154381 recommendation. Somehow "nix64" was assigned as "active debugger"
I configured it as "gdb14-64" (see attach 1 ) and assigned it to the toolchain (see attach 1), replacing native gdb form this toolchain, "nix64" (see attach 1).
However, old "nix64" gdb is jumping out when I`m trying to debug (see attach 1). In default.conf all looks ok (attach 2), when I hacked "nix64" profile to use ssbssa gdb, it worked. Looks like somewhere in depth of the C::B old profile, "nix64", is not replaced with new one "gdb14-64".
"So it goes" (с)
Update: Problem was resolved according to https://forums.codeblocks.org/index.php/topic,22724.msg154381.html#msg154381 recommendation. Somehow "nix64" was assigned as "active debugger"