txx28 wrote:When I moved the line init() in the constructor, that did the trick and WindowBuilder Pro correctly recognized the UI.
I would argue that WB correctly recognized that the class had no exposed UI the first time around. Having an
init() method but not calling it makes that code a no-op.
txx28 wrote:However, it failed to load a component from following statement
Sounds more like a bug in the component that caused it to fail/crash when instantiated. WB would typically replace it with a red error placeholder and report the error from the component in the log.
txx28 wrote:where XXXComponent is another class residing in the same file as XXX
While that will work, this is a VERY BAD design practice. A Java file should never contain more than one top-level class.
txx28 wrote:WindowBuilder Pro correctly recognised it.
WB "recognized" it just fine either way. In the latter case, I would guess that the component itself did not crash.
txx28 wrote:Evidently this==null was causing the problem and WindowBuilder Pro somehow could not parse it.
WB can parse it just fine. However, there is no "this" at design time, so that would be null. The component has the responsibility to properly handle a null input in this case. If the component crashes, the component has a bug that should be fixed. In general, a custom Swing component should follow standard Java Bean guidelines and provide a zero-argument constructor. It should also be very defensive about any arguments that it does require. It sounds like XXXComponent violates both of those rules.
txx28 wrote:But, the program is written by another developer and not me who has used a lot of spaghetti code.
In that case, how far WB gets with this will depend on how good or bad that spaghetti code is. WB makes no promises that it will be able to parse any arbitrary hand-written Java code. It does amazing well with 90% of what is out there (especially if it is reasonably well structured and follows typical Java/Swing rules).
txx28 wrote:So, I am neither allowed to replace this with new XXX() nor I can move the call to init() in constructor as it MIGHT break program logic. I traced call to init() and it was called from a method in one class which was itself being called from method of yet another class. I understand this is lot of spaghetti there. Same is the case with most GUI classes which the programmer has written.
With code that convoluted and which apparently ignores common Java/Swing coding standards, I would hold out very little hope that WB will be of much use to you.
txx28 wrote:Being a programmer, I CAN DEFINITELY UNDERSTAND THAT IT IS SIMPLY IMPOSSIBLE TO IMAGINE IN HOW MANY WAYS A GUI CLASS CAN BE WRITTEN, ESPECIALLY A GUI CLASS WHOSE COMPONENTS ARE BEING BUILT BY CALLING FUNCTIONS SPREAD ALL OVER DIFFERENT CLASSES.
Quite true.
txx28 wrote:A program like WindowBuilder Pro can only be written when there is some "structure" / some "organization" for GUI class. WindowBuilder Pro can keep adding more "intelligence" to it but, frankly, there will be no end to this - considering the bewildering ways in which a programmer can construct a GUI class.
WB has an enormous amount of intelligence in this regard, but there are limits that we would not choose to go beyond even if we could. At some point, it is an actual disservice to support bad coding and design practices - both to the developer trying to code that way and to other users of WB (due to the distraction and drain on our development resources to support bizarre one-off cases).
txx28 wrote:So here is my point : I WISH TO KNOW HOW A GUI CLASS NEEDS TO BE "STRUCTURED" OR "ORGANIZED" SO THAT IT CAN BE PARSED CORRECTLY BY WindowBuilder Pro. This way, I can be sure that when I add/edit/delete something in WindowBuilder Pro GUI designer, it will be reflected correctly in GUI class code. So, bidirectionality is important.
Any reasonably well structured Java/Swing class should be fine. We try to put as few restrictions on that as possible. In general, WB starts with the constructor and does a data flow analysis from there. It is concerned with static UI code and will ignore any dynamic constructs that it finds (code inside loops, conditions, event handlers, etc.). Any UI code that is directly reachable from the constructor should render in the design view. Custom components that are referenced from the class being edited should follow standard Java Bean guidelines and should not assume a specific runtime context that does not exist at design time. Any runtime specific code should be properly protected with either null checks, isDesignTime() checks, etc. See the WB FAQ for more on what is parseable and what is not and what is expected from custom components.
Did you read the FAQ? It touches on a number of the above issues. If there are specific issues that you feel that it does not adequately address, let us know.
txx28 wrote:I can generate all types of different layouts, GUIs, components, etc and study the resulting generated code.
In general, this is a very good idea.
txx28 wrote:Nevertheless, I am hooked to WindowBuilder Pro because its been widely praised and surely there is some substance to it.
I believe that the praise is well earned