Parser error and a best practice [message #616975] |
Tue, 04 March 2008 12:56 |
Marco Maniscalco Messages: 30 Registered: July 2009 |
Member |
|
|
Hy folks,
I just wondered why so many people get parser errors while using VE. Most of
the time "illegal" user modifications are the source of VE's parsing
problems. Final member variables, illegal changes to generated methods, and
so on. I did not find any documentation on how people can extend a generated
visual class without destroying it. (Correct me if I'm wrong).
In fact, VE is not as customizable as it could be. I would like to customize
the code-generation, so some trivial patterns could be applied to avoid
editing generated classes (or at least reduce it to a minimum).
A good practice is maybe making all members and initializers protected.
public class MyGui {
protected Shell sShell = null; //
@jve:decl-index=0:visual-constraint="10,10"
protected Combo combo = null;
protected ComboViewer comboViewer = null;
protected void createSShell() {
sShell = new Shell();
sShell.setText("Shell");
createCombo();
sShell.setSize(new Point(417, 169));
sShell.setLayout(new GridLayout());
}
protected void createCombo() {
combo = new Combo(sShell, SWT.NONE);
comboViewer = new ComboViewer(combo);
}
}
Because then I could derive a class MyGuiImpl:
public class MyGuiImpl extends MyGui {
public MyGuiImpl() {
// where I easily can access the UI code, mainly the members of the
UI
this.createSShell();
this.combo.setText("My UI logic");
}
}
The benefit would be the fact, that the generated source will never be
touched and all ui-logic implementation is outside and can not corrupt the
ui-instantiation code.
Do You have other suggestions on how you would solve this?
Greets Marco
|
|
|
Powered by
FUDForum. Page generated in 0.04677 seconds