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.
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.
@RJPComputingI'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.
@GromIf 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.