Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » e(fx)clipse » Dynamic Part Rendering Problem(Dynamically created part appears to render over the top of the incorrect pane.)
Dynamic Part Rendering Problem [message #1695565] Sat, 16 May 2015 21:28 Go to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
I have done a two step conversion of some e4 code from SWT to e(fx)clipse and run into a problem on the last step of the conversion with code related to the creation of dynamic parts. The code worked previously under SWT, but now I am having issues when executing under e(fx)clipse.

My development environment is:
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600
e(fx)clipse - 1.2.0.201501301049
java.runtime.version=1.8.0_40-b25
os=Windows 7 x86_64

My runtime target is the same.

I have a compound window arrangement in my e4 Application Model using Part Sash Containers to split the window right and left, and then split the right side top and bottom between a detail Part Stack and a support Part Stack somewhat similar to a Java PDE framing (Explorer on the left; Detail code on the right top part; problems, console, etc. on the right bottom). Parts in the "support" area (problems, console, etc.) are created dynamically as needed.

The issue is that when I create a "support part" dynamically the "Part" itelf is correctly created and opened within its defined PartStack element, however the content for that part as created by the ContributionURI class is created with rendering on top of one of the other parts in the window rather than within the confines of the new Part. Placement of the rendering appears somewhat random, but seems to paint on top of the currently "active" component prior to the new part being created.

I have used two different versions of code to create the dynamic part and seem to have the same results with both versions. Can someone tell me if there is something that I am doing wrong, or is this a bug with e(fx)clipse 1.2.0? I have tried to search for it in the forums and on bugzilla but cannot find any similar problem descriptions.

Method 1: Part Descriptor

MPart findResultPart = null;
MPartStack partStack = perspective.getSupportPartStack();

findResultPart = partService.createPart(PART_DESCRIPTOR);
findResultPart.setElementId("uniqueId");
partStack.setVisible(true);
partStack.getChildren().add(findResultPart);
partService.activate(findResultPart, true);

Method 2: Factory Method

MPart findResultPart = null;
MPartStack partStack = perspective.getSupportPartStack();

findResultPart = MBasicFactory.INSTANCE.createPart();
findResultPart.setElementId("uniqueId");
findResultPart.setContributionURI(BUNDLECLASS + SEARCH_RESULTS_PART);
findResultPart.setContainerData("Container:AnchorPane");
partStack.setVisible(true);
partStack.getChildren().add(findResultPart);
partService.activate(findResultPart, true);

I also use the Part Descriptor method to create dynamic parts for the detail area of the window (when selecting from the "explorer") and that code seems to always work correctly. The one thing that I can think of that is different in the case where I am having issues is that the Part Stack is originally hidden (not visible) until the first time a part is created to be placed in that area. However, once the problem occurs, it continues with new ContributionURI rendering directed to whichever (incorrect) pane that happens to have focus at the time of the rendering.
Re: Dynamic Part Rendering Problem [message #1695688 is a reply to message #1695565] Mon, 18 May 2015 13:22 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Would you be able to create a dummy javafx application which allows me
to reproduce the problem?

It really should be very minimal. If you have such a thing please file a
bug and I'll look into fixing it - your code itself looks ok BTW and if
it used to work in e4/SWT it should run in e4/JavaFX as well.

I guess the code uses the SWTFX port?

Tom

On 18.05.15 14:50, Joe Van Steen wrote:
> I have done a two step conversion of some e4 code from SWT to
> e(fx)clipse and run into a problem on the last step of the conversion
> with code related to the creation of dynamic parts. The code worked
> previously under SWT, but now I am having issues when executing under
> e(fx)clipse.
>
> My development environment is:
> Version: Luna Service Release 2 (4.4.2)
> Build id: 20150219-0600
> e(fx)clipse - 1.2.0.201501301049
> java.runtime.version=1.8.0_40-b25
> os=Windows 7 x86_64
>
> My runtime target is the same.
>
> I have a compound window arrangement in my e4 Application Model using
> Part Sash Containers to split the window right and left, and then split
> the right side top and bottom between a detail Part Stack and a support
> Part Stack somewhat similar to a Java PDE framing (Explorer on the left;
> Detail code on the right top part; problems, console, etc. on the right
> bottom). Parts in the "support" area (problems, console, etc.) are
> created dynamically as needed.
>
> The issue is that when I create a "support part" dynamically the "Part"
> itelf is correctly created and opened within its defined PartStack
> element, however the content for that part as created by the
> ContributionURI class is created with rendering on top of one of the
> other parts in the window rather than within the confines of the new
> Part. Placement of the rendering appears somewhat random, but seems to
> paint on top of the currently "active" component prior to the new part
> being created.
> I have used two different versions of code to create the dynamic part
> and seem to have the same results with both versions. Can someone tell
> me if there is something that I am doing wrong, or is this a bug with
> e(fx)clipse 1.2.0? I have tried to search for it in the forums and on
> bugzilla but cannot find any similar problem descriptions.
>
> Method 1: Part Descriptor
>
> MPart findResultPart = null;
> MPartStack partStack = perspective.getSupportPartStack();
>
> findResultPart = partService.createPart(PART_DESCRIPTOR);
> findResultPart.setElementId("uniqueId");
> partStack.setVisible(true);
> partStack.getChildren().add(findResultPart);
> partService.activate(findResultPart, true);
>
> Method 2: Factory Method
>
> MPart findResultPart = null;
> MPartStack partStack = perspective.getSupportPartStack();
>
> findResultPart = MBasicFactory.INSTANCE.createPart();
> findResultPart.setElementId("uniqueId");
> findResultPart.setContributionURI(BUNDLECLASS +
> SEARCH_RESULTS_PART);
> findResultPart.setContainerData("Container:AnchorPane");
> partStack.setVisible(true);
> partStack.getChildren().add(findResultPart);
> partService.activate(findResultPart, true);
>
> I also use the Part Descriptor method to create dynamic parts for the
> detail area of the window (when selecting from the "explorer") and that
> code seems to always work correctly. The one thing that I can think of
> that is different in the case where I am having issues is that the Part
> Stack is originally hidden (not visible) until the first time a part is
> created to be placed in that area. However, once the problem occurs, it
> continues with new ContributionURI rendering directed to whichever
> (incorrect) pane that happens to have focus at the time of the rendering.
Re: Dynamic Part Rendering Problem [message #1695692 is a reply to message #1695688] Mon, 18 May 2015 13:29 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
On 18.05.15 15:22, Tom Schindl wrote:
> Would you be able to create a dummy javafx application which allows me
> to reproduce the problem?

Just to make it clear it should be an e4 javafx application!

Tom
Re: Dynamic Part Rendering Problem [message #1695734 is a reply to message #1695692] Mon, 18 May 2015 17:27 Go to previous messageGo to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
Tom,

Thanks for your reply. I tried to shorten my problem code for the sake of brevity in the post. However, after posting the note I thought of two other differences between code that works, and the code that fails.

1- In the code that works I launched the new Part from another active Part, in the failing code I am launching from a command executor.
2- In the code that works I have no concerns about passing variables, in the code that fails I am passing variables.

This last point, the passing of variables through the context is where I think I am having the issues and seeing the inconsistency. I think the problem is not a function of the part creation methodology, but appears to be an inconsistency between the way that SWT and JavaFX versions of e4 handle rendering and context management of dynamically created parts. My assumption was that the significant change between these version was limited to GUI technology changes. That does not appear to be the case.

In the code under SWT I created a new child context for the new part and set named variables in the context to pass data to be injected into the new part. The context was created as a child of the Perspective context and set on the Part before the Part was instantiated. On debugging the assignment of a created context seems critical to the strange rendering of the new part. Elimination of that process, and allowing the e(fx)clipse infrastructure to create the Part context eliminated the "randomly placed" rendering issue. However, this left me with the problem of how to convey the information to be passed. If I attach a context and set variables I get the rendering issues. If I don't then the rendering problem doesn't happen, but the context gets created, the class is instantiated and the PostConstruct method fires all as one process as soon as I attach the Part to the PartStack.

I followed the process documented at hxxp://tomsondev.bestsolution.at/2013/11/21/writing-ieclipsecontext-less-code/ but ran into the same problem as described in the e(fx)clipse forum post hxxps://www.eclipse.org/forums/index.php?t=msg&th=689085/.

I am in the process of trying to play with that now, but it is not what I want to do. That appears to be for dynamic variables which I want the part to monitor and share with others. I just want a simple input paramater variable to be fed to the new Part.

Do you have a test case for a simple input parameter pass to a dynamic part that you can point me to?

FYI - This code was originally developed as e4/SWT code. I wanted to convert it to JavaFX. My original approach was to work my way up from the bottom and I used FXCanvas to convert GUI panes and left the main branching SWT. Once that was all finished, I set about migrating the core. That work has been completed and the application now runs as a org.eclipse.fx.ui.workbench.fx.application. So far almost everything else seems to be working fine. The only other issue I am having is finding out why my toolbar disappeared.
Re: Dynamic Part Rendering Problem [message #1695735 is a reply to message #1695734] Mon, 18 May 2015 17:28 Go to previous messageGo to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
links modified due hxxps due to forum moderation constraints.
Re: Dynamic Part Rendering Problem [message #1695742 is a reply to message #1695735] Mon, 18 May 2015 20:40 Go to previous messageGo to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
For the record, I now have my code working using the:

@Inject
@ContextValue(value="search_result")
ContextBoundValue<List<C_AF_UiElementData>> ctxSearchResult;

technique with the inclusion of setting the passed variables as modifiable. I then went back to trying my old scheme to try to re-create the problem. This time I again get an error with the old (simple parameter pass) but it was slightly different. The frame for the new Part renders, but rather than rendering the content in a strange place I get the error below. Note, for this error I had again created by own IEclipseContext as a child of the current PerspectiveContext, set the variables in the new child context and set the context on the Part before I added the Part to the PartStack.

!ENTRY org.eclipse.e4.ui.workbench 4 0 2015-05-18 13:21:57.884
!MESSAGE Unable to create class 'net.architectedfutures.eats.air.ui.parts.C_AF_ElementsSearchResultsView' from bundle '11'
!STACK 0
org.eclipse.e4.core.di.InjectionException: Unable to process "C_AF_ElementsSearchResultsView.part": no actual value was found for the argument "MPart".
at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:416)
at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:407)
at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:109)
at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:337)
at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:258)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:104)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:73)
at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:55)
at org.eclipse.fx.ui.workbench.renderers.base.BasePartRenderer.doProcessContent(BasePartRenderer.java:220)
at org.eclipse.fx.ui.workbench.renderers.base.BasePartRenderer.doProcessContent(BasePartRenderer.java:1)
at org.eclipse.fx.ui.workbench.renderers.base.BaseRenderer.processContent(BaseRenderer.java:672)
at org.eclipse.fx.ui.workbench.fx.PartRenderingEngine.createGui(PartRenderingEngine.java:191)
at org.eclipse.fx.ui.workbench.fx.PartRenderingEngine.createGui(PartRenderingEngine.java:288)
at org.eclipse.fx.ui.workbench.renderers.base.BaseRenderer.engineCreateWidget(BaseRenderer.java:592)
at org.eclipse.fx.ui.workbench.renderers.base.BaseStackRenderer$7.call(BaseStackRenderer.java:305)
at org.eclipse.fx.ui.workbench.renderers.base.BaseStackRenderer$7.call(BaseStackRenderer.java:1)
at org.eclipse.fx.ui.workbench.renderers.fx.DefStackRenderer$StackItemImpl.handleSelection(DefStackRenderer.java:397)
at org.eclipse.fx.ui.workbench.renderers.fx.DefStackRenderer$StackWidgetImpl$4.changed(DefStackRenderer.java:212)
at org.eclipse.fx.ui.workbench.renderers.fx.DefStackRenderer$StackWidgetImpl$4.changed(DefStackRenderer.java:1)
at com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:182)
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:81)
at javafx.beans.property.ReadOnlyObjectWrapper$ReadOnlyPropertyImpl.fireValueChangedEvent(ReadOnlyObjectWrapper.java:176)
at javafx.beans.property.ReadOnlyObjectWrapper.fireValueChangedEvent(ReadOnlyObjectWrapper.java:142)
at javafx.beans.property.ObjectPropertyBase.markInvalid(ObjectPropertyBase.java:112)
at javafx.beans.property.ObjectPropertyBase.set(ObjectPropertyBase.java:146)
at javafx.scene.control.SelectionModel.setSelectedItem(SelectionModel.java:102)
at javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:717)
at javafx.scene.control.TabPane$TabPaneSelectionModel.select(TabPane.java:735)
at javafx.scene.control.TabPane$TabPaneSelectionModel.findNearestAvailableTab(TabPane.java:794)
at javafx.scene.control.TabPane$TabPaneSelectionModel.lambda$new$17(TabPane.java:691)
at javafx.scene.control.TabPane$TabPaneSelectionModel$$Lambda$449/308910536.onChanged(Unknown Source)
at com.sun.javafx.collections.ListListenerHelper$Generic.fireValueChangedEvent(ListListenerHelper.java:329)
at com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:73)
at javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:233)
at javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482)
at javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541)
at javafx.collections.ObservableListBase.endChange(ObservableListBase.java:205)
at javafx.collections.ModifiableObservableListBase.addAll(ModifiableObservableListBase.java:102)
at org.eclipse.fx.ui.workbench.renderers.fx.DefStackRenderer$StackWidgetImpl.addItems(DefStackRenderer.java:284)
at org.eclipse.fx.ui.workbench.renderers.fx.DefStackRenderer$StackWidgetImpl.addItems(DefStackRenderer.java:290)
at org.eclipse.fx.ui.workbench.renderers.base.BaseStackRenderer.handleChildrenAddition(BaseStackRenderer.java:354)
at org.eclipse.fx.ui.workbench.renderers.base.BaseStackRenderer$1.handleEvent(BaseStackRenderer.java:89)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler$1.run(UIEventHandler.java:40)
at org.eclipse.fx.ui.workbench.fx.internal.UISynchronizeImpl.syncExec(UISynchronizeImpl.java:73)
at org.eclipse.e4.ui.services.internal.events.UIEventHandler.handleEvent(UIEventHandler.java:36)
at org.eclipse.equinox.internal.event.EventHandlerWrapper.handleEvent(EventHandlerWrapper.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:197)
at org.eclipse.equinox.internal.event.EventHandlerTracker.dispatchEvent(EventHandlerTracker.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148)
at org.eclipse.equinox.internal.event.EventAdminImpl.dispatchEvent(EventAdminImpl.java:135)
at org.eclipse.equinox.internal.event.EventAdminImpl.sendEvent(EventAdminImpl.java:78)
at org.eclipse.equinox.internal.event.EventComponent.sendEvent(EventComponent.java:39)
at org.eclipse.e4.ui.services.internal.events.EventBroker.send(EventBroker.java:81)
at org.eclipse.e4.ui.internal.workbench.UIEventPublisher.notifyChanged(UIEventPublisher.java:59)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java:374)
at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(EcoreEList.java:249)
at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:294)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:303)
at net.architectedfutures.eats.air.ui.handlers.C_AF_FindCommandHandler.execute(C_AF_FindCommandHandler.java:259)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.fx.ui.workbench.renderers.base.BaseItemRenderer.executeAction(BaseItemRenderer.java:207)
at org.eclipse.fx.ui.workbench.renderers.base.BaseMenuItemRenderer$1.run(BaseMenuItemRenderer.java:50)
at org.eclipse.fx.ui.workbench.renderers.fx.DefMenuItemRenderer$MenuItemImpl$2$1.run(DefMenuItemRenderer.java:132)
at com.sun.javafx.application.PlatformImpl.lambda$null$170(PlatformImpl.java:295)
at com.sun.javafx.application.PlatformImpl$$Lambda$56/2030908282.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$171(PlatformImpl.java:294)
at com.sun.javafx.application.PlatformImpl$$Lambda$55/991884888.run(Unknown Source)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$145(WinApplication.java:101)
at com.sun.glass.ui.win.WinApplication$$Lambda$44/288731526.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)

Re: Dynamic Part Rendering Problem [message #1695743 is a reply to message #1695734] Mon, 18 May 2015 20:40 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,

If i get you right you do:

-------8<--------
MPart p ....;
IEclipseContext c = ....;
p.setContext(c);
-------8<--------

You are never supposed to create the context of the part - this is
something that's only to be managed by the framework! If this worked in
SWT this only worked by chance.

One solution on this would be that you push the information into the
transientData of the MPart and invent your own annotation (@TransientData)

----------8<----------
MPart p = ...;
p.getTransientData().put("bla",new Data());

class MyPart {
@Inject
@TransientData("bla")
Data bla;
}
----------8<----------

Tom

On 18.05.15 19:27, Joe Van Steen wrote:
> Tom,
>
> Thanks for your reply. I tried to shorten my problem code for the sake
> of brevity in the post. However, after posting the note I thought of two
> other differences between code that works, and the code that fails.
> 1- In the code that works I launched the new Part from another active
> Part, in the failing code I am launching from a command executor.
> 2- In the code that works I have no concerns about passing variables, in
> the code that fails I am passing variables.
>
> This last point, the passing of variables through the context is where I
> think I am having the issues and seeing the inconsistency. I think the
> problem is not a function of the part creation methodology, but appears
> to be an inconsistency between the way that SWT and JavaFX versions of
> e4 handle rendering and context management of dynamically created parts.
> My assumption was that the significant change between these version was
> limited to GUI technology changes. That does not appear to be the case.
>
> In the code under SWT I created a new child context for the new part and
> set named variables in the context to pass data to be injected into the
> new part. The context was created as a child of the Perspective context
> and set on the Part before the Part was instantiated. On debugging the
> assignment of a created context seems critical to the strange rendering
> of the new part. Elimination of that process, and allowing the
> e(fx)clipse infrastructure to create the Part context eliminated the
> "randomly placed" rendering issue. However, this left me with the
> problem of how to convey the information to be passed. If I attach a
> context and set variables I get the rendering issues. If I don't then
> the rendering problem doesn't happen, but the context gets created, the
> class is instantiated and the PostConstruct method fires all as one
> process as soon as I attach the Part to the PartStack.
>
> I followed the process documented at
> hxxp://tomsondev.bestsolution.at/2013/11/21/writing-ieclipsecontext-less-code/
> but ran into the same problem as described in the e(fx)clipse forum post
> hxxps://www.eclipse.org/forums/index.php?t=msg&th=689085/.
>
> I am in the process of trying to play with that now, but it is not what
> I want to do. That appears to be for dynamic variables which I want the
> part to monitor and share with others. I just want a simple input
> paramater variable to be fed to the new Part.
>
> Do you have a test case for a simple input parameter pass to a dynamic
> part that you can point me to?
>
> FYI - This code was originally developed as e4/SWT code. I wanted to
> convert it to JavaFX. My original approach was to work my way up from
> the bottom and I used FXCanvas to convert GUI panes and left the main
> branching SWT. Once that was all finished, I set about migrating the
> core. That work has been completed and the application now runs as a
> org.eclipse.fx.ui.workbench.fx.application. So far almost everything
> else seems to be working fine. The only other issue I am having is
> finding out why my toolbar disappeared.
Re: Dynamic Part Rendering Problem [message #1695747 is a reply to message #1695743] Mon, 18 May 2015 22:03 Go to previous messageGo to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
Tom,
Thank you again. I used the technique you explained above with TransientData and it worked fine, except I was unable to pick up the data via
@Inject @TransientData ...

Instanead I used:

@Inject
MPart part;
inputData = part.getTransientData().get("input key");

This worked fine.

In terms of my use of creating the context of the part and passing the data that way it did work consistently under SWT and, in fact, I obtained the technique from pp 45-46 of:

Instant Eclipse 4 RCP Development How-to
by Ram Kulkarni, Published by Packt, 2013
ISBN 978-1-78216-952-9

I guess there may be others following along in the future who may have the same issue. Thanks for your help and I will use the TransientData technique for this type of problem in the future.
Re: Dynamic Part Rendering Problem [message #1695752 is a reply to message #1695747] Mon, 18 May 2015 23:12 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hi,
On 19.05.15 00:03, Joe Van Steen wrote:
> Tom,
> Thank you again. I used the technique you explained above with
> TransientData and it worked fine, except I was unable to pick up the
> data via @Inject @TransientData ...
>
> Instanead I used:
>
> @Inject
> MPart part;
> inputData = part.getTransientData().get("input key");
>

The draw back with your code is that now your UI code depends on the e4
application model which is not a good a perfect design ;-)

The @TransientData naturally does not exist yet but you'd have to
develop your own one.

How complex is that data you want to publish? Is it easily serializable
eg through JAXB?

I guess our upcoming Memento-Support in 2.0 could be of great help in
this regard [1]. Currently this is bound directly to the persistedState
but we could extend its useage to the transientData.

So you'd write something like this:

class MyPart {
@PostConstruct
public void init(@Named("TransientMemento") Memento memento) {
MyData data = memento.get("input key", MyData.class, null);
// ....
}
}

> This worked fine.
>
> In terms of my use of creating the context of the part and passing the
> data that way it did work consistently under SWT and, in fact, I
> obtained the technique from pp 45-46 of:
>
> Instant Eclipse 4 RCP Development How-to
> by Ram Kulkarni, Published by Packt, 2013
> ISBN 978-1-78216-952-9

Then those guys simply don't understand Eclipse 4 - sorry but this is
really really wrong, the IEclipseContext of the model elements is the
job of the framework and nobody is allowed to modify it and even
creating your own ones (for your own code!) is not as simply as many
people think it is!

Tom

[1]https://wiki.eclipse.org/Efxclipse/Runtime/Recipes#UI-State_Persistence_with_Memento-Interface
Re: Dynamic Part Rendering Problem [message #1695753 is a reply to message #1695747] Mon, 18 May 2015 23:20 Go to previous messageGo to next message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
FYI, I posted a note to Ram Kulkarni's blog to advise him to review this thread regarding possible publication of errata for the book, or to revise the techniques if he publishes a new revision.
Re: Dynamic Part Rendering Problem [message #1695756 is a reply to message #1695752] Mon, 18 May 2015 23:55 Go to previous message
Joe Van Steen is currently offline Joe Van SteenFriend
Messages: 25
Registered: March 2015
Junior Member
Tom,
I understand the issue about staying away from the infrastructure elements, and so have no problem changing the code. For what I was doing in this case I can convert to the Memento concept when I move up to Mars and your 2.0 code level. These were two parameter being passed from search process to search UI (criteria for the search, and result set). I just share similar data using the same names with multiple "search result" UI parts, NOT a changing set of results with a single Part.

However, I can also conceive of situations where I may want to pass a live object for the exclusive use of one process who may monitor it for change. Not where the object changes, but where it's properties may change. If the object changed, my understanding is that DI would propagate that notice. But if internal properties were to change that need to be noticed, a reference needs to be passed to the live object, and then serialization wouldn't work ... correct?

In this last case of passing a live object would I still want to be using the TransientData solution?

For passing a changing series of similar objects to the same Part, and probably for passing and sharing the same data with multiple Parts my current tendency would be to use the @Inject @ContextValue scheme.
Previous Topic:FXML to Java Code
Next Topic:javafx classes are not recogized under Mars and e(fx)clipse 2.0
Goto Forum:
  


Current Time: Sat Mar 30 07:00:37 GMT 2024

Powered by FUDForum. Page generated in 0.02771 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top