Thanks,
Joe
Your suggestion was exactly what I
needed.
It turns out that there are (at
least) two ways to get SWT on your classpath/build
path:
1) The
method Joe just mentioned.
2) By
creating a plug-in that lists SWT as a dependency.
VE currently only works with method #1. I was using
#2.
Dave
Dave,
Opening an existing class requires
parsing and this work is on-going right now. The one that works best
right now is the top-down scenario is the one to try - visit the build path of
the project, Add Library, select "Standard Widget Toolkit" to get the
container added. Open Empty.java, the SWT stuff is on the platte, drop a
Shell from here. Drop other stuff into it, resize and move them around
and use the property sheet to change properties.
Best regards,
Joe Winchester
Please respond to
ve-dev@xxxxxxxxxxx
Sent by:
ve-dev-admin@xxxxxxxxxxx
To:
"'ve-dev@xxxxxxxxxxx'"
<ve-dev@xxxxxxxxxxx>
cc:
Subject: RE: [ve-dev] SWT code patterns
I got excited when I saw the screen
shots below and wanted to see this work for myself. So
I:
- Got the
latest CVS build from head.
- Deleted the
package Gili mentioned in a previous post.
-
Created the following class (by hand), inside VE:
public class
SWTTest {
org.eclipse.swt.widgets.Shell shell = null;
private void
createShell() {
shell =
new org.eclipse.swt.widgets.Shell();
shell.setSize(new
org.eclipse.swt.graphics.Point(640, 480));
}
}
If I
open VE on this class using the Package Explorer, it chugs for a second
or so, then I get a NPE dialog. When I hand-coded this inside VE,
I got nothing...
What am I doing wrong?
(I'd *love* to do a short, tightly scripted demo of VE
for SWT at EclipseCon next week during the VE session. Not to
mention that this is just way cool!)
Dave
-----Original Message-----
From: Dr Gili Mendel [mailto:gmendel@xxxxxxxxxx]
Sent: Thursday, January 29, 2004 2:43
PM
To: ve-dev@xxxxxxxxxxx;
wsjve-dev@xxxxxxxxxxxxxxxxxxxxxx
Subject:
[ve-dev] SWT code patterns
We are in
the process of creating a skeleton SWT enabled driver to form the bases
from which to build the SWT extensions. An important part of it
is the code generation/parsing patterns that we intend to support.
We need to iterate on this a until we get it right. The
first milestone goal (for the iteration process) is to have a driver
that can generate/parse similar patterns to the driver that we have
today. The problem is getFoo() for SWT controls do not make any
sense... so we need to move forward a bit.
.... so we are holding the following first
iteration goal assumptions which do not require any VE modeling
changes:
- One will not be able to drop anything but a Shell or
a parentless widget (e.g. Dialog) on the Free Form. If one is to
customize a Composite, they will use the create-wizard to create a
class that extends a Composite with a constructor that takes a parent
(need to talk more about flags). The target VM will know how to
parent the "this" part on the free form.
- Dropping a Shell will produce an instance variable,
private org.eclipse.swt.widgets.Shell
shell = null, and a create method
private void createShell ()
(private vs. public is tbd).
- Dropping a child on a container will create an
instance variable for the child, and reuse the parents initialization
method. ... it will produce the following code/EMF model
[IMAGE]
Instance variables are created since both the
shell and the button are contained in the root membership of the model
(vs. a membership owned by a methods element - a local variable).
The "controls" feature denotes the parent/child relationship.
The initializes feature of the methods element denotes that
createShell is used to initialize both the shell/button.
This pattern would create a single
method per top component.
=======================================================
Note that with bottom up
parsing, VE will also recognize the following:
[IMAGE]
In this case we have the same shell and a button
as a child. Both are instance variables, but each is initialized by a
different method.
The key here
is that createShell() must call the create method of the button.
In the case that
the createButton() _expression_ is removed from createShell(),
CodeGen will remove the button (and if needed its init
method) from the VE EMF model... which implies that the GUI will only
show the Shell.
...
this is a first pass to the scenario where as a createButton() exists,
but no one (that we can understand) calls it. The WYSIWYG Free Form
will reflect that.
This milestone does not take into consideration factory
methods.
------------
Dr. Gili Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408, tie:
441 6408