CTabItem more than once visible in SWT designer

[nocomm]

Hi, I have the following "feature" in SWT designer:

In my application there are multiple CTabItems that only get activated, when they are selected from the menu. So, in the code, I define these CTabItems at the beginning, as usually, to see them in SWT designer and graphically add and edit elements on each CTabItem.
In my menuSelection()-method I check if the selected CTabItem is already visible (it can be removed from the workspace with the "X"-button, just like in Eclipse) and, if not, I have to recreate the instance of the CTabItem (the elements on it are still there) to show the tab again.
Now, in the SWT designer, each CTabItem, that has the ability to be recreated (over the menuSelection()), is shown twice (as the SWT designer obviously checks for "new CTabItem(...)"). Only one of the two occurences in the Designer tab then holds the elements of the CTabItem.

My question is now, if there is a possibility to hide these second occurences of the CTabItems, which are just for enabling the display, and only see the tabs where elements are defined on it?!

Thanks for any help
nocomm

[Eric Clayberg]

My question is now, if there is a possibility to hide these second occurences of the CTabItems, which are just for enabling the display, and only see the tabs where elements are defined on it?!

I would suggest refactoring the code so that new CTabItem(...) is only called once for each tab item. You could, for example, use the Extract Method refactoring to extract the creation of the CTabItem (and its children) into a new createTabItem() method. If the parent CTabFolder is a field, this new method won't even need any arguments. You can then call that method inline with the creation of the rest of the widgets and also from within your menuSelection() method (or only the latter, if you prefer).

[nocomm]

sometimes the solution is just so obvious that one can't see it....

Thanks for your suggestion - good workaround...

[Eric Clayberg]

sometimes the solution is just so obvious that one can't see it....
Thanks for your suggestion - good workaround...

I should point out that the only reason the above work around is even possible is due to the fact that Designer has a very powerful parser and internal model. This makes it very refactoring-friendly. You can modify and restructure your code in many ways, and Designer will still be able to interpret it. As you then continue to modify your design, Designer will make changes in the correct places based on your restructuring rather than rewriting all of the code to follow some static template (as most GUI builder would do). As you can see, there is no reason for us to mark any methods as sacred to the GUI builder or insert any "user code goes here" comments (user code can go anywhere).