Open eliasvasylenko opened 4 years ago
So I've come back to this the following morning, and it appears that something like the following is possible as a fairly straightforward work around:
// move to front of shared elements list
window.getSharedElements().remove(sharedElement);
window.getSharedElements().add(0, sharedElement);
// make not visible in window
sharedElement.setVisible(false);
// create UI and directly get node
presentationEngine.createGui(sharedElement, null, context);
var node = (Node) ((WWidget<?>) sharedElement.getWidget()).getWidget();
But it would be nice if hostElement
worked directly!
It's also worth noting that nothing is done with the parentWidget
parameter in createGui
, hence the need to manually cast to WWidget
to get the widget node.
Currently the way
EModelService::hostElement
is implemented can't work due to a problem with how UI elements in a window's shared elements list are handled by the renderer.I have only tested this with an
MPartStack
, but I think it will be the same for anything based on my understanding of the problem.Basically, when you try to render an element which is a shared element, the renderer tries to add it as a normal child of the window.
So for example if it is at index 6 in the shared elements list, and the window currently has fewer than 6 children, we get an IndexOutOfBounds exception when the renderer tries to add the element at the position of the 6th child.
If the index in the shared elements list is lower than the number of children of the window then the element is erroneously added to the list of the window's direct children and rendered in the root of the window.
Here is an example stack trace of the failing case: