[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] SWT code patterns
|
Title: Message
Never
mind. I got this figured out.
At this point the decoders only generate (will parse shortly in a few
days).... the pattern it generates now is not the one we are
proposing.
Understood.
Add SWT to your project's class path, but adding the SWT
container
I'm
not sure what you mean by this. I make all of my SWT projects plug-in
projects so that I can use the PDE to regenerate my .classpath whenever I
switch platforms from Windows to Linux or vice versa.
SWT
is currently on my classpath.
Start with an empty class (extends Object) Drop a shell, and then a
composite on the shell.
I
don't see either Shell or Composite on the palette. I tried dropping via
"Use Bean", and I got the drag mouse cursor, dragged, then I saw a bunch of
code appear then disappear quickly in the code editor, then
nothing.
(I
CVS update'd to HEAD today.)
Thanks,
Dave
------------
Dr. Gili
Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408,
tie: 441 6408
Dave Orme
<DaveO@xxxxxxxxxxxxxxx> Sent by: ve-dev-admin@xxxxxxxxxxx
01/30/2004 10:53 AM
|
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
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:
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