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 |
Joe Van Steen 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 |
Thomas Schindl 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 #1695734 is a reply to message #1695692] |
Mon, 18 May 2015 17:27 |
Joe Van Steen 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 #1695743 is a reply to message #1695734] |
Mon, 18 May 2015 20:40 |
Thomas Schindl 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 #1695752 is a reply to message #1695747] |
Mon, 18 May 2015 23:12 |
Thomas Schindl 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 #1695756 is a reply to message #1695752] |
Mon, 18 May 2015 23:55 |
Joe Van Steen 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.
|
|
|
Goto Forum:
Current Time: Sat Mar 30 07:00:37 GMT 2024
Powered by FUDForum. Page generated in 0.02771 seconds
|