Home » Modeling » EMF » custom widgets with EMF
| |
| Re: custom widgets with EMF [message #417230 is a reply to message #417222] |
Mon, 03 March 2008 05:26   |
 Ron Bermejo
Messages: 30
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Charles,
> I've been looking at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220843 just this weekend.
> All the new data binding support seems relevant as well
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625.
Hi, Ed, Charles.
Now that you've mentioned databinding, it seems
https://bugs.eclipse.org/bugs/show_bug.cgi?id=144260 might be related,
too, if we want to perform cell editing.
Personally I like the AdapterFactory*Provider approach since we can add
adapter factories via extension points, so my tables can show any type of
data (future-proof = nice:)) . Thus it works well for me in the model->UI
direction.
Databinding adds UI->model updating, validation, but it doesn't seem
"unified" with the AdapterFactory approach. Currently I can only choose
one or the other. (e.g. either use
EMFObservables.observeList+ObservableListContentProvider, or use
AdapterFactoryContentProvider).
I vaguely wish there was a way I could get the best of both worlds, but
right now I have no idea how that API would look like. :)
[/off-topic]
-Ron
> Charles Martin wrote:
>> Hi
>> Are there any examples of custom widgets being made that are EMF-enabled
that one can look at
>>
>> As a first step, I would like to create a view that has a table and also
some text boxes
>>
>> I have an EMF model that contains a list of children (to be displayed in
the table) and some attributes (to be display in the text boxes)
>>
>> I guess what I am thinking is to make an AdapterFactoryContentProvider
that can provide content to the table and the text boxes. I am wondering if
there is anything like that out there to look at
>>
>> Best wishes
>>
>> Charles
>>
|
|
|
| Re: custom widgets with EMF [message #417236 is a reply to message #417230] |
Mon, 03 March 2008 12:22 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Ron,
There's a lot of content in that bug and unfortunately I don't
understand data binding as well as I should. I was hoping Marcelo and
Dave could dive deeply into it, but that darned book is dragging on
forever. It's dragging on so long that it's starting to look like we'd
better include EMF 2.4 in the appendix (where including EMF 2.3 is
already a lot of work with all the generics). Anyway, enough whining.
It will be a best seller I'm sure!
I wonder if the whole topic is related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216748 as well? This
looks a bit like a failed approach, given Boris poked so many holes in
it. Or I wonder if the binding to a table couldn't simply take the
approach of being based on IPropertySource. I'm certainly open to
suggestions and contributions if you have any...
Ron Bermejo wrote:
> Ed Merks wrote:
>
>> Charles,
>
>> I've been looking at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324 and
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220843 just this
>> weekend. All the new data binding support seems relevant as well
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625.
>
> Hi, Ed, Charles.
>
> Now that you've mentioned databinding, it seems
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=144260 might be related,
> too, if we want to perform cell editing.
>
>
> Personally I like the AdapterFactory*Provider approach since we can
> add adapter factories via extension points, so my tables can show any
> type of data (future-proof = nice:)) . Thus it works well for me in
> the model->UI direction.
>
> Databinding adds UI->model updating, validation, but it doesn't seem
> "unified" with the AdapterFactory approach. Currently I can only
> choose one or the other. (e.g. either use
> EMFObservables.observeList+ObservableListContentProvider, or use
> AdapterFactoryContentProvider).
>
> I vaguely wish there was a way I could get the best of both worlds,
> but right now I have no idea how that API would look like. :)
> [/off-topic]
>
> -Ron
>
>> Charles Martin wrote:
>>> Hi
>>> Are there any examples of custom widgets being made that are
>>> EMF-enabled
> that one can look at
>>>
>>> As a first step, I would like to create a view that has a table
>>> and also
> some text boxes
>>>
>>> I have an EMF model that contains a list of children (to be
>>> displayed in
> the table) and some attributes (to be display in the text boxes)
>>>
>>> I guess what I am thinking is to make an
>>> AdapterFactoryContentProvider
> that can provide content to the table and the text boxes. I am
> wondering if there is anything like that out there to look at
>>>
>>> Best wishes
>>>
>>> Charles
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: custom widgets with EMF [message #417257 is a reply to message #417236] |
Tue, 04 March 2008 08:00 |
Charles H Martin
Messages: 79
Registered: July 2009 |
Member |
|
|
Wow...lots of reading :D
Actually, what I was thinking was something very simple, to handle the static cases I have
(Forgive me if this is repeated in the bugs or just naive)
The current mechanism for binding EMF models to JFace viewers is to add an interface to the specific ItemProviders
For example, in my case, I have
MyTableItemProvider implements ITableItemLabelProvider
(from org.eclipse.emf.edit.provider)
and to add this interface to the supportedTypes:
public MyAppItemProviderAdapterFactory() {
supportedTypes.add(ITableItemLabelProvider.class);
}
The problem is that this only works for the JFace Viewers, and what I want is to construct a View that has multiple JFace viewers in it. Use cases of complex views might include
(a) TableViewer + some Text Fields (what I need)
(b) Two tree Viewers
(c) List Viewer + Tree Viewer
(d) multiple Text Fields
I am assuming, however, that I have a singlke EMF model and that it maps naturally to these Views of the Model.
For example, my MyTable model includes some children and some attributes, and these children map naturally into a table row, and the attributes can be displayed in some text fields. Likewise for the other cases
Now imagine if I could define a custom interface for my view, such as IMyViewContentProvider so that MyTableItemProvider implements it.
IMyViewContentProvider might implement
getTableChildren(Object obj, int colIndex)
getText(Object obj)
My job should be to implement the logic that marshals these calls into the corresponding method on MyTableItemProviders:
getTableChilden(Object obj, int colIndex) {
return this.getChildren(obj, colIndex)
}
and
getText(Object obj) {
if (obj instanceof MyObj) return MyTable.getMyObj().getText()
}
The missing part is that it seems I would need to add my new interface to the AdapterFactoryItemDelegator , and then implement similar logic
...
although it is not entirely clear to me if that is all there is or what that logic should be
It also seems to me that if it is much more complicated than this, then something is off. I would think this is a common problem people have ?
|
|
|
| Re: custom widgets with EMF [message #417263 is a reply to message #417257] |
Tue, 04 March 2008 11:14 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Charles,
Comments below.
Charles Martin wrote:
> Wow...lots of reading :D
>
> Actually, what I was thinking was something very simple, to handle the static cases I have
>
> (Forgive me if this is repeated in the bugs or just naive)
>
> The current mechanism for binding EMF models to JFace viewers is to add an interface to the specific ItemProviders
> For example, in my case, I have
>
> MyTableItemProvider implements ITableItemLabelProvider
> (from org.eclipse.emf.edit.provider)
>
> and to add this interface to the supportedTypes:
>
> public MyAppItemProviderAdapterFactory() {
> supportedTypes.add(ITableItemLabelProvider.class);
> }
>
>
> The problem is that this only works for the JFace Viewers, and what I want is to construct a View that has multiple JFace viewers in it.
Well, you'd use the same approach for each one.
> Use cases of complex views might include
>
> (a) TableViewer + some Text Fields (what I need)
> (b) Two tree Viewers
> (c) List Viewer + Tree Viewer
> (d) multiple Text Fields
>
EMF 2.4 includes support for data binding which is another useful
mechanism that can be applied for binding the values of features onto
specific controls for manipulating, such as text fields.
> I am assuming, however, that I have a singlke EMF model and that it maps naturally to these Views of the Model.
> For example, my MyTable model includes some children and some attributes, and these children map naturally into a table row, and the attributes can be displayed in some text fields. Likewise for the other cases
>
The table and table tree pretty much work like this already. The
regular item providers, without the ITableColumnItemProvider stuff, can
and are used to populate the rows of the table, and the first row can be
used to display the normal text and icons (as in a list or tree) for
those objects. The other columns can be used to display additional
information. With the two classes contributed to JFace, it will be
possible to create a column that corresponds exactly to a property you
can edit in the properties view. I.e., the column shows the value for
the property and supports a cell editor for editing it.
> Now imagine if I could define a custom interface for my view, such as IMyViewContentProvider so that MyTableItemProvider implements it.
>
> IMyViewContentProvider might implement
>
> getTableChildren(Object obj, int colIndex)
> getText(Object obj)
>
> My job should be to implement the logic that marshals these calls into the corresponding method on MyTableItemProviders:
>
>
> getTableChilden(Object obj, int colIndex) {
> return this.getChildren(obj, colIndex)
> }
>
> and
>
> getText(Object obj) {
> if (obj instanceof MyObj) return MyTable.getMyObj().getText()
> }
>
I don't think anything needs to be added to support this case. In fact,
I doubt you'd need to add anything this fancy. The existing item
provider stuff supports the structured viewing, and the combination of
properties support for data binding support deals with the finer grained
controls, like text fields, radio buttons, and so on.
>
> The missing part is that it seems I would need to add my new interface to the AdapterFactoryItemDelegator , and then implement similar logic
>
> ...
>
> although it is not entirely clear to me if that is all there is or what that logic should be
>
> It also seems to me that if it is much more complicated than this, then something is off. I would think this is a common problem people have ?
>
Yep, but I think the pieces are all in place already for it...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: custom widgets with EMF [message #417278 is a reply to message #417277] |
Tue, 04 March 2008 16:19 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010500030504040006020803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Charles,
EMF.Edit is designed to be platform neutral and hence has no
dependencies on JFace, SWT, or anything else GUI related. The generated
item providers too have no GUI or Eclipse dependencies. Integration
with Eclipse is provided in a layer on top of these. I.e., there is
support for cell editing via the Eclipse properties view, but that's
done in the EMF.Edit.UI layer. With the advent of ColumnViewers and the
support just committed to the platform for using
IPropertySource/IPropertyDescriptors for table columns, this support can
be reused for cell editing in tables simply by defining a property.
It's somewhat involved to provide custom cell editors, but definitely is
doable:
3.1 Recipe: Create your own property editor in a generated
application
< http://wiki.eclipse.org/EMF/Recipes#Recipe:_Create_your_own_ property_editor_in_a_generated_application>
Charles Martin wrote:
> I think I see this now
>
> Let me ask you this, which is kinda related IU guess
>
> Why doesn't the default ITableItemProvider provide some kind of configurable table cell editing?
>
> Or does it?
>
--------------010500030504040006020803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Charles,<br>
<br>
EMF.Edit is designed to be platform neutral and hence has no
dependencies on JFace, SWT, or anything else GUI related. The
generated item providers too have no GUI or Eclipse dependencies.
Integration with Eclipse is provided in a layer on top of these. I.e.,
there is support for cell editing via the Eclipse properties view, but
that's done in the EMF.Edit.UI layer. With the advent of ColumnViewers
and the support just committed to the platform for using
IPropertySource/IPropertyDescriptors for table columns, this support
can be reused for cell editing in tables simply by defining a
property. It's somewhat involved to provide custom cell editors, but
definitely is doable:<br>
<blockquote><a
href=" http://wiki.eclipse.org/EMF/Recipes#Recipe:_Create_your_own_ property_editor_in_a_generated_application"><span
class="tocnumber">3.1</span> <span class="toctext">Recipe: Create
your own property editor in a generated application</span></a><br>
</blockquote>
<br>
Charles Martin wrote:
<blockquote
cite="mid:28511928.33431204647090606.JavaMail.root@cp1.dzone.com"
type="cite">
<pre wrap="">I think I see this now
Let me ask you this, which is kinda related IU guess
Why doesn't the default ITableItemProvider provide some kind of configurable table cell editing?
Or does it?
</pre>
</blockquote>
<br>
</body>
</html>
--------------010500030504040006020803--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: custom widgets with EMF [message #417280 is a reply to message #417279] |
Tue, 04 March 2008 16:53 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000902080500080205040202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Charles,
Given the new classes in the platform, setting up a column that edits a
property is just a few lines of code:
| {
TreeColumn treeColumn = *new *TreeColumn(tree, SWT.NONE);
treeColumn.setText("Name");
treeColumn.setResizable(*true*);
treeColumn.setWidth(200);
TreeViewerColumn treeViewerColumn = *new *TreeViewerColumn(treeViewerWithColumns, treeColumn);
treeViewerColumn.setLabelProvider(*new *PropertyColumnLabelProvider(adapterFactoryContentProvider, "Name"));
treeViewerColumn.setEditingSupport(*new *PropertyEditingSupport(treeViewerWithColumns, adapterFactoryContentProvider, "Name"));
}|
I'm sure the platform has all kinds of snippets for this kind of thing,
but I don't know where. Tom often posts links to them...
Charles Martin wrote:
> Thanks...I'll have a look at this over the next few days and see if I can get the table cell editing working.
>
> Where can I find out about ColumnViewers? The last time I had editable columns I had to add a selectionListener to the table, and then create custom textEditors on the selection...(i.e from the SWT snippets page)
>
> BTW, is there an EMF snippets page somewhere?
>
> Charles
>
--------------000902080500080205040202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Charles,<br>
<br>
Given the new classes in the platform, setting up a column that edits a
property is just a few lines of code:<br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff"> </font><font
color="#000000">{</font><br>
<font color="#ffffff"> </font><font color="#000000">TreeColumn treeColumn = </font><font
color="#7f0055"><b>new </b></font><font color="#000000">TreeColumn</font><font
color="#000000">(</font><font color="#000000">tree, SWT.NONE</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">treeColumn.setText</font><font
color="#000000">(</font><font color="#2a00ff">"Name"</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">treeColumn.setResizable</font><font
color="#000000">(</font><font color="#7f0055"><b>true</b></font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">treeColumn.setWidth</font><font
color="#000000">(</font><font color="#990000">200</font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000"> TreeViewerColumn treeViewerColumn =&nb sp; </font><font
color="#7f0055"><b>new </b></font><font color="#000000">TreeViewerColumn</font><font
color="#000000">(</font><font color="#000000">treeViewerWithColumns, treeColumn </font><font
color="#000000">)</font><font color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">treeViewerColumn.setLabelProvider</font><font
color="#000000">(</font><font color="#7f0055"><b>new </b></font><font
color="#000000">PropertyColumnLabelProvider</font><font color="#000000">(</font><font
color="#000000">adapterFactoryContentProvider, </font ><font
color="#2a00ff">"Name"</font><font color="#000000">))</font><font
color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">treeViewerColumn.setEditingSupport</font> <font
color="#000000">(</font><font color="#7f0055"><b>new </b></font><font
color="#000000">PropertyEditingSupport</font><font color="#000000">(</font><font
color="#000000"> treeViewerWithColumns, adapterFactoryContentProvide r, </font><font
color="#2a00ff">"Name"</font><font color="#000000">))</font><font
color="#000000">;</font><br>
<font color="#ffffff"> </font><font color="#000000">}</font></code>
</td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
I'm sure the platform has all kinds of snippets for this kind of thing,
but I don't know where. Tom often posts links to them...<br>
<br>
<br>
Charles Martin wrote:
<blockquote
cite="mid:5130900.33621204649135507.JavaMail.root@cp1.dzone.com"
type="cite">
<pre wrap="">Thanks...I'll have a look at this over the next few days and see if I can get the table cell editing working.
Where can I find out about ColumnViewers? The last time I had editable columns I had to add a selectionListener to the table, and then create custom textEditors on the selection...(i.e from the SWT snippets page)
BTW, is there an EMF snippets page somewhere?
Charles
</pre>
</blockquote>
<br>
</body>
</html>
--------------000902080500080205040202--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: custom widgets with EMF [message #417295 is a reply to message #417280] |
Tue, 04 March 2008 18:24 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Ed Merks schrieb:
> Charles,
>
> Given the new classes in the platform, setting up a column that edits a
> property is just a few lines of code:
>
> | {
> TreeColumn treeColumn = *new *TreeColumn(tree, SWT.NONE);
> treeColumn.setText("Name");
> treeColumn.setResizable(*true*);
> treeColumn.setWidth(200);
> TreeViewerColumn treeViewerColumn = *new *TreeViewerColumn(treeViewerWithColumns, treeColumn);
> treeViewerColumn.setLabelProvider(*new *PropertyColumnLabelProvider(adapterFactoryContentProvider, "Name"));
> treeViewerColumn.setEditingSupport(*new *PropertyEditingSupport(treeViewerWithColumns, adapterFactoryContentProvider, "Name"));
> }|
>
>
> I'm sure the platform has all kinds of snippets for this kind of thing,
> but I don't know where. Tom often posts links to them...
>
We have plenty of them ;-) http://wiki.eclipse.org/JFaceSnippets. I
think we have a snippet for all our APIs, if something is missing let me
know and I'll try to create a snippet.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
| | | | | | | | |
| Re: custom widgets with EMF [message #417416 is a reply to message #417409] |
Mon, 10 March 2008 00:19 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi Charles,
I had this problem recently. What I did (and what I understand from Ed's
answer) is just use @generated NOT, on the ItemProvider class in (1) and
in the ItemProviderAdapterFactory constructor for (2).
One trick that I found, in the case of (1), though, is that when you
change your metamodel, you need to be careful about the ItemProvider
classes when you regenerate, because the @generated NOT applies to the
whole class, not just the declaration/extends/inherits line.
If the metamodel change effects the class with the additional Item/Label
Provider interfaces, then you need to regenerate the ItemProvider fully,
in order to get generated methods like addXPropertyDescriptor(), then
re-add the additional interfaces to the inherits clause. Its a pain, but
not having the property descriptor methods is (potentially) worse.
If Ed or someone else wants to tell me a better way, I'm happy to hear it.
Cheers,
Jim.
Ed Merks wrote:
> Charlies,
>
> Comments below.
>
> Charles Martin wrote:
>> Actually I have a question about this too...
>>
>> When I modify my EMF models and regenerate the edit code, I lose some changes that I would like to preserve.
>>
>> (1) I lose the ITableItemLabelProvider Interface on the ItemProviderAdapaters
>>
> Here's an example:
>
> |/**|
> | * <!-- begin-user-doc -->|
> | * A representation of the model object '<em><b>EEnum Literal</b></em>'.|
> | * *@extends Enumerator*|
> | * <!-- end-user-doc -->|||||
> | */|
> |*public interface *EEnumLiteral *extends *ENamedElement, *Enumerator*|
> |{|
>
>> (2) I lose the
>> supportedTypes.add(ITableItemLabelProvider.class);
>>
>> in the constuctor for the ItemProviderAdapterFactory
>>
>> Is there a simple way to preserve these?
>>
> You can add "NOT" to the @generated to avoid it ever being regenerated
> again.
>
|
|
|
| Re: custom widgets with EMF [message #417418 is a reply to message #417416] |
Mon, 10 March 2008 12:11 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Jim,
Comments below.
Jim Steel wrote:
>
> Hi Charles,
>
> I had this problem recently. What I did (and what I understand from
> Ed's answer) is just use @generated NOT, on the ItemProvider class in
> (1) and in the ItemProviderAdapterFactory constructor for (2).
An @generated NOT (as opposed to say @generated not) on a class or
interface has special meaning. It blocks all merging for the entire
class Just using "@generated not" just blocks merging for the
class/interface itself, but not for the nested contents. Using
@extends/@implements is much better, since all merging behavior is
preserved. It's also important when building a model from @model
annotations, since it will instruct the JavaEcoreBuilder that the
classes/interfaces mentioned in the @extends are not part of the model....
>
> One trick that I found, in the case of (1), though, is that when you
> change your metamodel, you need to be careful about the ItemProvider
> classes when you regenerate, because the @generated NOT applies to the
> whole class, not just the declaration/extends/inherits line.
Yes. That's generally a bad thing. So use it with caution.
>
> If the metamodel change effects the class with the additional
> Item/Label Provider interfaces, then you need to regenerate the
> ItemProvider fully, in order to get generated methods like
> addXPropertyDescriptor(), then re-add the additional interfaces to the
> inherits clause. Its a pain, but not having the property descriptor
> methods is (potentially) worse.
>
> If Ed or someone else wants to tell me a better way, I'm happy to hear
> it.
I think I tried to explain the better way with @extends. Using
@generated NOT on and interface or class is pretty much the worst way
for the reasons you've spelled out.
>
> Cheers,
>
> Jim.
>
>
>
>
> Ed Merks wrote:
>> Charlies,
>>
>> Comments below.
>>
>> Charles Martin wrote:
>>> Actually I have a question about this too...
>>>
>>> When I modify my EMF models and regenerate the edit code, I lose
>>> some changes that I would like to preserve.
>>> (1) I lose the ITableItemLabelProvider Interface on the
>>> ItemProviderAdapaters
>>>
>> Here's an example:
>>
>> |/**|
>> | * <!-- begin-user-doc -->|
>> | * A representation of the model object '<em><b>EEnum
>> Literal</b></em>'.|
>> | * *@extends Enumerator*|
>> | * <!-- end-user-doc -->|||||
>> | */|
>> |*public interface *EEnumLiteral *extends *ENamedElement,
>> *Enumerator*|
>> |{|
>>
>>> (2) I lose the supportedTypes.add(ITableItemLabelProvider.class);
>>>
>>> in the constuctor for the ItemProviderAdapterFactory
>>>
>>> Is there a simple way to preserve these?
>>>
>> You can add "NOT" to the @generated to avoid it ever being
>> regenerated again.
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | | |
| Re: custom widgets with EMF [message #425878 is a reply to message #425874] |
Wed, 10 December 2008 19:04 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Jonas,
Are you having a specific problem? It would help to provide some
details of what you're trying to achieve...
Generally the content/label provider delegates via the adapter factory
to item providers, so to specialize what a view shows, you'd specialize
the item providers. If you want multiple different "views" you'd need
multiple specialized factories that create different specialized item
providers. XSDSemanticItemProviderAdapterFactory is a specific example
of a specialized "semantic" verses "concrete syntax" view of the XSD
model...
Jonas Wolf wrote:
> Hi,
>
> I'd like to step in here again, because I think the question about
> several different views on one model was not answered yet.
> But this is what I am currently looking for. How to do this?
> Any hints, links or snippets are highly appreciated.
> Thanks in advance and sorry for being stupid if this question is
> already answered somewhere or just trivial.
>
> jonas
>
> Ed Merks wrote:
>> Charles,
>>
>> No, the viewers have an input that control what's displayed. Setting
>> the selection just controls the selection within the established
>> view's contents.
>>
>>
>> Charles Martin wrote:
>>> Wow, this is pretty bleeding edge
>>>
>>> Ok, let me ask about one more permutation of the original question.
>>>
>>> Suppose I want to build a GUI with several different views of the
>>> same EMF model. Is it simply a matter of setting the selection in
>>> viewer:
>>>
>>> currentViewer.setSelection(new
>>> StructuredSelection(theSelection.toArray()), true)
>>>
>>> to the subset of the model?
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | |
Goto Forum:
Current Time: Tue Apr 23 17:50:10 GMT 2024
Powered by FUDForum. Page generated in 0.04972 seconds |
] 
Search
Help
Register
Login
Home
