Community
Participate
Working Groups
In GEF 3.2M2, transferring (copy-pasting or dragging) assumes that the given template is the factory. This causes a problem when the factory is from a different editor. Currently, it is the clients' responsibility to verify that the part being pasted/dropped in the viewer is of a type it understands. However, most clients won't be aware of that and will likely run into some problem (Logic example encounters a ClassCastException). A potential solution is to make the clients provide some sort of a context id that would prevent the transferring of a type to a viewer that does not support it.
Steve, this new function is going to cause problem. See class TTDTL. It used to be abstract, but now clients can use it directly. Also see CombinedTemplateCreationEntry. A new constructor added there allows factories to be the template.
Changing to RESOLVE WONTFIX based on the above comments. Reporter to re-open with more information if enhancement is still required.
Why was this marked as WONTFIX? This is still a problem and should be fixed. Don't know if it can be fixed without changing API (which means it might not be fixable in the maintenance release).
We encountered this problem "in the field", so it's no longer a what-if. Increasing severity.
