Refactoring causes controls to vanish from Designer View

[romilly]

Hi Eric,

I've recently started using WBPro. It's a joy to use. With it and "Eclipse - building commercial quality plug-ins" I've been able to build a complex SWT gui in a couple of days, with no previous SWT experience.

However, I'm experiencing unexpected and undesirable behaviour when editiing an SWT composite.

The composite contains a sashForm. I factored out the code that creates the two groups within the sashForm; when I reopened the editor the next day, the groups were visible in Designer but their children were not. (The composite still worked when used in its application).

I inlined the creation code for the group on the left side of the sashFrame and the contents of the group reappered; I then inlined the code for the right side; again, the other group contents reappeared.

What's happening?

I can send you the "before" and "after"code if this would help.

[Eric Clayberg]

The composite contains a sashForm. I factored out the code that creates the two groups within the sashForm; when I reopened the editor the next day, the groups were visible in Designer but their children were not. (The composite still worked when used in its application). I inlined the creation code for the group on the left side of the sashFrame and the contents of the group reappered; I then inlined the code for the right side; again, the other group contents reappeared. What's happening?

If I had to guess, I would say that one of your refactoring transformations made the code ambiguous or unparseable by the Designer parser. One general rule is that the code needs to represented by a top down tree where every widget is created by its own unique section of code. It doesn't matter what the method names are or how nested they are, as long as two or more widgets aren't created by the same block of code. This means that you can't create multiple widgets in a loop, and you can't call the same method twice to create two different sets of controls. If you were refactoring the code to extract common elements, you could get into that situation. Inlining the code would have then resulted in each widget being represented by its own block of code.

Someday, we may enhace the tool to support ths kind of code, but it gets tricky in the UI when multiple widgets share the same code. Changing the settings on one widget would, in effect, change the settings on all widgets sharing the same code. Some operations or transformations would not even be possible or could lead to very undesirable results.

I can send you the "before" and "after"code if this would help.

Yes. That would be very helpful. I could tell you very quickly what it didn't like. Your Eclipse ".log" might also contain more details.