Eclipse Community Forums: Visual Editor (VE)

Help

Home

Home » Archived » Visual Editor (VE) » VE code pattern question

Show: Today's Messages :: Show Polls :: Message Navigator

VE code pattern question [message #106167]

Mon, 12 September 2005 14:28

Greg Renegar

Messages: 18
Registered: July 2009

Junior Member

Hi, I am trying to use VE for swing UI and have a problem as follows..

I have a JToolbar that adds a JButton. (see code below) This will render
perfectly in VE design view. However, if I uncomment the
'//addStaffCommand.setCaller(this);' line I get buggy rendering and the
following warning:

java.lang.IllegalArgumentException( ...AddStaffCommand.setCaller
( ...StaffInternalFrame): "argument type mismatch")

I know for a fact that this is NOT an argument type mismatch as
parameter is of type StaffInternalFrame in caller and receiver.

Also, I gather that one must always use empty constructors, then set
fields after object creation.

Sorry if this is dumb question, I an new to VE. Also, is there a
resource (other than this newsgroup) for information about coding for VE
compliance? So far it is trial and error method and very frustrating.

private JButton getAddButton() {
if (addButton == null) {
addButton = new JButton();
addButton.setAction(getAddAction());
if (addButton.getIcon() != null) {
addButton.setText(""); //an icon-only button
}
}
return addButton;
}

private AddAction getAddAction() {
if (addStaffAction == null) {
addStaffAction = new AddAction(); // a class that extends
AbstractAction
addStaffAction.setCommand(getAddStaffCommand());
}
return addStaffAction;
}

private AddStaffCommand getAddStaffCommand() {
if (addStaffCommand == null) {
if ( !java.beans.Beans.isDesignTime() ) {
addStaffCommand = new AddStaffCommand();
//addStaffCommand.setCaller(this);
}
}
return addStaffCommand;
}

Many thanks,
Greg

Report message to a moderator

Re: VE code pattern question [message #106224 is a reply to message #106167]

Mon, 12 September 2005 15:04

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

The problem here is that when using VE and referencing "this". For the
"this" object we can't instantiate the true "this" because that is the
class you are editing. Since it is being edited and is constantly
changing there is no .class file to use. So instead we instantiate the
superclass of the class being edited. This usually works ok because the
"this" is usually not be used or if it is, it is being used as the
superclass. But in your case the "this" part is directly a
StaffInternalFrame and not inherit from.

This is currently a restriction that we can't get around.

Also, we don't actually execute ANY methods that are implemented
directly within the "this" class itself. They are interpreted only.
Again this is because we can execute the this class since it is being
edited at that time and is constantly changing. Because of this, the
check for !isDesignTime is unnecessary because we don't interpret
control expressions. We only interpret assignments and method call
statements. So even though you had a !isDesignTime around the
addStaffCommand we don't see the test and so we still try to interpret
the code within the if expression.
>
> private AddStaffCommand getAddStaffCommand() {
> if (addStaffCommand == null) {
> if ( !java.beans.Beans.isDesignTime() ) {
> addStaffCommand = new AddStaffCommand();
> //addStaffCommand.setCaller(this);
> }
> }
> return addStaffCommand;
> }
>
> Many thanks,
> Greg

--
Thanks,
Rich Kulp

Report message to a moderator

Re: VE code pattern question [message #106236 is a reply to message #106224]

Mon, 12 September 2005 16:08

Greg Renegar

Messages: 18
Registered: July 2009

Junior Member

Thank you very much for your prompt, clear reply.

> Also, we don't actually execute ANY methods that are implemented
> directly within the "this" class itself. They are interpreted only.
> Again this is because we can execute the this class since it is being
> edited at that time and is constantly changing. Because of this, the
> check for !isDesignTime is unnecessary because we don't interpret
> control expressions. We only interpret assignments and method call
> statements. So even though you had a !isDesignTime around the
> addStaffCommand we don't see the test and so we still try to interpret
> the code within the if expression.

Is there a way to tell VE to ignore code? The code causing the problem
in VE is not visual in nature anyways. This is what I hoped to
accomplish with !isDesignTime, but I understand now why that fails.

In the bigger picture, I am wondering what the best approach should be
for visual class code architecture so that VE does not break...

My basic desire is to have a visual class (StaffInternalFrame) that uses
separate command classes to encapsulate the work for the visual class,
keeping the visual class relatively uncluttered. Is there a way to do
this that is compatible with VE? I wonder if you have a small sample
swing application, or perhaps sample code excerpts, to illustrate
techniques that will not break VE?

Of interest to me in this specific case is how to attach 'worker' code
to a jMenuItem & JButton such that the worker code can be non-trivial
(encapsulated in separate classes?), while retaining a clean visual (ui)
class, without breaking VE.

Thank you very much for your help with this. I LOVE eclipse and really
want VE to work for our large swing app!

Greg

Report message to a moderator

Re: VE code pattern question [message #106251 is a reply to message #106236]

Mon, 12 September 2005 18:22

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

Generally we parse all of the code, but if we determine that it is not
an initialize method, then it will be discard and ignored.

An initialize method is one that has a "new" in it and assigns to a
variable. So what happened was it saw that the getAddStaffCommand was an
init method due to the "addStaffCommand = new AddStaffCommand();" stmt.
So it then knew that setCaller was a property of AddStaffCommand, so it
processed that too.

For now the workaround would be to create a private method that does the
setCaller on the addStaffCommand and then call that method from the
getAddStaffCommand method. In that case we wouldn't parse it.

This part of having to interpret the code causes problems as we get more
complicated stuff.

As to your question of separating the UI from the control code,
typically you would have a control class which creates the UI and then
returns the UI to be added to some parent UI. However, the current
implementation of VE can be used to create the UI class, but we don't
have a way yet of the "controller" giving up the UI instance when it is
used on another parent visual. We are working on this concept now for
SWT (TreeViewer is an example of this, where the TreeViewer is a
controller and the visual is a Tree, but when we use a TreeViewer, we
want to see the Tree).
--
Thanks,
Rich Kulp

Report message to a moderator