User forums > Using Code::Blocks
WxFormBuilder ...WxSmith
Grom:
wxFormBuider doesn't support events generation in the same sense as wxSmith and wxDevCpp. I can't modify the generated text of the program!!!. This is the weakest point of it. I didn't start using wxSmith for all forms and panels of my project only because it doesn't have wxGrid in components palette. The custom build components probably will solve that problem. BYO is making a good work and Code::Blocks team has to help him a lot.
RJP Computing:
I think more disscusion about wxFormBuilder should move to the official wxFormBuilder forum. :)
--- Quote from: Grom on April 17, 2007, 05:24:08 pm ---wxFormBuider doesn't support events generation in the same sense as wxSmith and wxDevCpp. I can't modify the generated text of the program!!!. This is the weakest point of it.
--- End quote ---
Well I completely beg to differ. This is a strong point of it in my opinion. I used to think that it wasn't the best way to write the GUI code, but after using it for some time it is the only way to go. It keeps your GUI code separated from your implementation of the user interface events and initialization. Once you give it a change it really cleans up your code. Plus there is no chance that a program is going to overwrite any of your code. ;)
rjmyst3:
--- Quote from: RJP Computing on April 17, 2007, 05:39:36 pm ---
--- Quote from: Grom on April 17, 2007, 05:24:08 pm ---wxFormBuider doesn't support events generation in the same sense as wxSmith and wxDevCpp. I can't modify the generated text of the program!!!. This is the weakest point of it.
--- End quote ---
Well I completely beg to differ. This is a strong point of it in my opinion. I used to think that it wasn't the best way to write the GUI code, but after using it for some time it is the only way to go. It keeps your GUI code separated from your implementation of the user interface events and initialization. Once you give it a change it really cleans up your code. Plus there is no chance that a program is going to overwrite any of your code. ;)
--- End quote ---
@RJPComputing
I'm not sure that you clarified things for Grom.
As I understand it, Grom is saying that the code that wxFB generates is not useful because it cannot be edited. So it seems like there is no way to modify the GUI with wxFB after the generated code has been integrated into an application.
@Grom
If that is how you perceived things, Grom, let me explain.
The classes that wxFB generates are intended to be used as base classes. The intent is that you never modify the files that wxFB generates, you create inherited classes for the forms in separate files. This separates functional code from gui layout code. So, when you modify the GUI with wxFB and regenerate, only the files containing the base classes are changed, and the files containing your implementation code are left untouched.
It is true that it takes a bit more effort to create those inherited classes for your implementation code, but there is a "GenerateInheritedClass" wizard to help with that.
RJPComputing assumed that you understood that (and maybe you did), and was explaining that he has come to prefer keeping gui and functional code in separate files, as opposed to the "normal" use of specialized comments to separate gui and functional code in the same file.
Grom:
The strategy of wxFormBuilder is not convenient... I can't navigate the events from GUI.
RJP Computing:
--- Quote from: Grom on April 18, 2007, 03:02:06 am ---The strategy of wxFormBuilder is not convenient... I can't navigate the events from GUI.
--- End quote ---
Not sure what you mean. It supports events. There is a tab for events and it supports events for all the main widgets. Check out the screen shots. Look under the 'Object Properties' on the right.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version