Visited Code

Swing Designer allows you to quickly create the frames, panels, dialogs, applets and other UI elements that comprise Java Swing applications.

Moderators: Konstantin.Scheglov, gnebling, Alexander.Mitin, jwren, Eric Clayberg

Visited Code

Postby txx28 » Mon Mar 14, 2011 7:58 pm

How can I "tell" WindowBuilder Pro / Swing Designer to visit a particular section of lines?

I have code like this

Code: Select all
public class XXX extends JFrame {
  JList bla1;
  JTextField bla2;
  JButton bla3;
  JCheckBox bla4;
//...

  public XXX() {  // Constructor
    super("XXX");
  }

  public void init() {
    Container p = getContentPane();
    p.setLayout(new BorderLayout());

    JPanel pn = new JPanel();
    pn.setBorder(new EmptyBorder(50, 50, 50, 50));
    p.add(pn, BorderLayout.CENTER);

    pn.setLayout(new BoxLayout(pn, BoxLayout.Y_AXIS));
// ...
}

// ... other code


As you can see, I am creating the frame in init() method. However init() method is never visited by WindowBuilder Pro. It visits just the following lines for ENTIRE class

Code: Select all
public class XXX extends JFrame {
  JList bla1;
  JTextField bla2;
  JButton bla3;
  JCheckBox bla4;
//...

  public XXX() {  // Constructor
    super("XXX");
  }


As a result, all I get is a completely EMPTY designer. The Components pane shows just 2 nodes in its tree.

(javax.swing.JFrame)
-- getContentPane()

But I am adding components in init() method. So, essentially, my problem is : How should I "tell" WindowBuilder Pro to visit the init() method so that it can parse it and generate a GUI in designer?

I am using Swing designer (no SWT and no GWT), if that matters.
txx28
 
Posts: 2
Joined: Mon Mar 14, 2011 7:34 pm

Re: Visited Code

Postby Eric Clayberg » Mon Mar 14, 2011 10:21 pm

Call the init() method from the constructor.

In your current example, you never call init() so WindowBuilder correctly ignores it.
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA

Re: Visited Code

Postby txx28 » Tue Mar 15, 2011 6:58 am

Thanks for the response! That was quick.

When I moved the line init() in the constructor, that did the trick and WindowBuilder Pro correctly recognized the UI. However, it failed to load a component from following statement

Code: Select all
    aVar = new XXXComponent(this);


where XXXComponent is another class residing in the same file as XXX but it is not an inner class of XXX. However, when I replaced above statement with

Code: Select all
    aVar = new XXXComponent(new XXX());


WindowBuilder Pro correctly recognised it. Evidently this==null was causing the problem and WindowBuilder Pro somehow could not parse it.

But, the program is written by another developer and not me who has used a lot of spaghetti code. 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.

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. 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.

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.

I read all through http://code.google.com/javadevtools/wbpro/ and it is indeed thorough and good, I could find no clues in it. I searched Google a lot to find this but I couldn't find anything. Google displayed some links to tutorials which were sooooo much written for a completely novice programmer. Thus, all my attempts to learn the "internals" of WindowBuilder Pro failed. Well, I can generate all types of different layouts, GUIs, components, etc and study the resulting generated code. But this is impossible as I don't have that much time. You know all about strict bosses, stricter deadlines and so on.

Nevertheless, I am hooked to WindowBuilder Pro because its been widely praised and surely there is some substance to it. Do you have such document ready with you? By the way, if you publish this, I am sure that it will not only help just me but a lot of serious developers of WindowBuilder Pro.

Thanks for reading my loooong post and please advice.

Kind Regards
txx28
 
Posts: 2
Joined: Mon Mar 14, 2011 7:34 pm

Re: Visited Code

Postby Eric Clayberg » Tue Mar 15, 2011 9:22 am

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.

txx28 wrote:I read all through http://code.google.com/javadevtools/wbpro/ and it is indeed thorough and good, I could find no clues in it.

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 ;-)
Eric Clayberg
Software Engineering Manager
Google
http://code.google.com/webtoolkit/download.html

Author: "Eclipse Plug-ins"
http://www.qualityeclipse.com
Eric Clayberg
Moderator
 
Posts: 4503
Joined: Tue Sep 30, 2003 6:39 am
Location: Boston, MA USA


Return to Swing Designer

Who is online

Users browsing this forum: No registered users and 1 guest

cron