| label providers [message #416120] |
Fri, 18 January 2008 12:47  |
Eclipse User |
|
|
|
Originally posted by: svylbowe.hotmail.com
Hi,
I've got the following structure in my view:
Component
- Service1
- Attribute1
- Service2
- Service2
- Entity1
- Entity2
As you can see, the object Service1 appears in different places in the tree.
How do I customize the label provider to take this into account.
Specifically, I want the label to state "implements Service2" when Service2
appears as a child of Service1.
- Anders
|
|
|
|
|
|
|
|
| Re: label providers [message #416151 is a reply to message #416149] |
Fri, 18 January 2008 19:00  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030103040805000302040006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Tom,
Certainly my understanding could be superseded by changes since I
looked. The update does seem to find multiple items now (since 3.2) but
only if there is an element map:
public void update(Object element, String[] properties) {
Assert.isNotNull(element);
Widget[] items = findItems(element);
for (int i = 0; i < items.length; i++) {
internalUpdate(items[i], element, properties);
}
}
* * @since 3.2*
*/
protected final Widget[] findItems(Object element) {
Widget result = doFindInputItem(element);
if (result != null) {
return new Widget[] { result };
}
// if we have an element map use it, otherwise search for the item.
if (*usingElementMap*()) {
Object widgetOrWidgets = elementMap.get(element);
if (widgetOrWidgets==null) {
return NO_WIDGETS;
} else if (widgetOrWidgets instanceof Widget) {
return new Widget[] {(Widget) widgetOrWidgets};
} else {
return (Widget[])widgetOrWidgets;
}
}
result = doFindItem(element);
return result == null ? NO_WIDGETS : new Widget[] { result };
}
It's really hard to keep up with the Jones's! The problem with the tree
path stuff from an EObject point of view is that we get a notification
directly on a given EObject and we can know a path based on eContainer,
but that's good only if that's the actual tree path being used by the
view. That's why if we have the same EObject in several places in the
tree (because of the use of non-containment references to induce the
tree) we kind of need (or used to anyway) a wrapper that is specific
each appearance in the tree...
Tom Schindl wrote:
> Ed Merks schrieb:
>> Tom,
>>
>> It seems to me the tree viewer won't expect to refresh multiple
>> instances of the same object when it's told to refresh a particular
>> object and in fact won't do it. It's also tricky to do the
>> notification for when the parent changes. I'm really not sure it
>> works, but of course the TreePath stuff came long after we did the
>> EMF.Edit support.
>>
>>
>
> I'm not sure I have understood what you are saying above.
>
> Well it depends how you call:
> => Viewer#update(object,null) it will update the labels of the object
> no matter where they are located in the Tree
> => Viewer#update(new TreePath(...),null) it will update only the label
> found at this specific path
>
> Tom
>
--------------030103040805000302040006
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">
Tom,<br>
<br>
Certainly my understanding could be superseded by changes since I
looked. The update does seem to find multiple items now (since 3.2)
but only if there is an element map:<br>
<br>
<small> public void update(Object element, String[] properties) {<br>
Assert.isNotNull(element);<br>
Widget[] items = findItems(element);<br>
<br>
for (int i = 0; i < items.length; i++) {<br>
internalUpdate(items[i], element, properties);<br>
} <br>
}<br>
<br>
<b> * @since 3.2</b><br>
*/<br>
protected final Widget[] findItems(Object element) {<br>
Widget result = doFindInputItem(element);<br>
if (result != null) {<br>
return new Widget[] { result };<br>
}<br>
// if we have an element map use it, otherwise search for the
item.<br>
if (<b>usingElementMap</b>()) {<br>
Object widgetOrWidgets = elementMap.get(element);<br>
if (widgetOrWidgets==null) {<br>
return NO_WIDGETS;<br>
} else if (widgetOrWidgets instanceof Widget) {<br>
return new Widget[] {(Widget) widgetOrWidgets};<br>
} else {<br>
return (Widget[])widgetOrWidgets;<br>
}<br>
}<br>
result = doFindItem(element);<br>
return result == null ? NO_WIDGETS : new Widget[] { result };<br>
}</small><br>
<br>
It's really hard to keep up with the Jones's! The problem with the
tree path stuff from an EObject point of view is that we get a
notification directly on a given EObject and we can know a path based
on eContainer, but that's good only if that's the actual tree path
being used by the view. That's why if we have the same EObject in
several places in the tree (because of the use of non-containment
references to induce the tree) we kind of need (or used to anyway) a
wrapper that is specific each appearance in the tree...<br>
<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:fmqr7k$i89$1@build.eclipse.org" type="cite">Ed
Merks schrieb:
<br>
<blockquote type="cite">Tom,
<br>
<br>
It seems to me the tree viewer won't expect to refresh multiple
instances of the same object when it's told to refresh a particular
object and in fact won't do it. It's also tricky to do the
notification for when the parent changes. I'm really not sure it
works, but of course the TreePath stuff came long after we did the
EMF.Edit support.
<br>
<br>
<br>
</blockquote>
<br>
I'm not sure I have understood what you are saying above.
<br>
<br>
Well it depends how you call:
<br>
=> Viewer#update(object,null) it will update the labels of the
object
<br>
no matter where they are located in the Tree
<br>
=> Viewer#update(new TreePath(...),null) it will update only the
label
<br>
found at this specific path
<br>
<br>
Tom
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------030103040805000302040006--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: label providers [message #416204 is a reply to message #416124] |
Tue, 22 January 2008 11:12 |
| Eclipse User |
|
|
|
Originally posted by: svylbowe.hotmail.com
Thanks a lot
-- Anders
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fmq9bd$ofh$1@build.eclipse.org...
> Anders,
>
> The JFace viewers rely on objects in the tree being unique. I.e., the
> object should appear at most once in the tree. So EMF uses wrappers when
> dealing with things like non-containment references that are likely to
> violate these assumptions. Such wrappers will know the parent to
> implement getParent correctly. So in ItemProviderAdapter there are
> methods like isWrappingNeeded and createWrapper for creating them as
> needed. It sounds like you could hook into this to create a wrapper that
> decorates the result in some specialized way depending on the parent...
>
>
> Anders H wrote:
>> Hi,
>>
>> I've got the following structure in my view:
>>
>> Component
>> - Service1
>> - Attribute1
>> - Service2
>> - Service2
>> - Entity1
>> - Entity2
>>
>> As you can see, the object Service1 appears in different places in the
>> tree.
> I only see it once. I guess you mean Service2. :-P
>> How do I customize the label provider to take this into account.
>> Specifically, I want the label to state "implements Service2" when
>> Service2 appears as a child of Service1.
>>
>> - Anders
>>
>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03655 seconds
] 
Search
Help
Register
Login
Home
