| Summary: | Get cut/copy/paste working | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Richard Kulp <richkulp> |
| Component: | VE | Assignee: | Joe Winchester <Winchest> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | daveo, gmendel, jzhang, klingelb, leo_welsch, mirko.riegel, Winchest |
| Version: | unspecified | Keywords: | usability |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Richard Kulp
Also, Forward cut/cop stuff (plus listener firings) in BeanFeatureEditor The cut/copy/paste stuff won't work correctly on wrappered bean cell editors because we are forwarded the requests correctly. Note: Need to be careful testing because Combobox type celleditors are wierd in that the ComboBox itself seems to steal the copy action. Need to trace that down. *** Bug 59372 has been marked as a duplicate of this bug. *** *** Bug 57018 has been marked as a duplicate of this bug. *** Note: This should also include cut/copy/paste from the Graph and Tree too. *** Bug 69834 has been marked as a duplicate of this bug. *** When we have Cur/Paste working, enable the ability to drop the same item from the palette multiple time (e.g., pressing the control key, while selecting a palette entry) We need to start with a Copy/Paste where in the first go around, we will duplicate all modeled settings (May not copy blocked comments before or after, or free form logical code). For events, we can: a) Not copy b) Generate Skelatons c) Copy the whole event's buddy over. The problem with c) is that it is quite likely that copying the code to a different method will result in compilation errors, as it is possible that the annonymous method referes to non-modeled/local instances. An option is a possibility here: give one a choice (with a dialog). A big question is how deep do we copy. Just property settings is easy. But what if they are shared settings, do you copy the apply but not the setting, what if in a different method. What about children? Do we determine children through the editpart being selected? If you select a panel, you expect the children to be copied too. Do we rely only on the "child" annotation on the feature? If we do, could we miss something? Should we merge the two, whatever is a child from the editpart AND what is child through annotation? Relying on the editpart could be a problem because on some parts the graphical doesn't have the same children as the tree (the tree usually has a superset). But relying on the "child" annoation is tricky because we don't always remember to set that annotation. The only formal way we can piggy back on is the feature's child annotation. For the Tree/Edit parts, I believe that events are the only diff. (Is menu items a problem as well?). We will have to clean up the child annotation as we go along. Cut/Copy/Paste options are available on the pop-up from the graph viewer, the tree viewer and also enabled from the Edit menu. The EMF model of the selected bean is copied, references are orphaned where appropiate, and the contents put into the clipboard as text. Paste on the graph viewer loads the cursor which allows the pasted part to be dropped at a particular position, and for the tree viewer paste is immediate as a child of the selected bean. VE 1.1. releaased. close bug. |