#104 closed defect (fixed)
renaming of connected elements in the visual editor fails
| Reported by: | steinmet | Owned by: | steinmet |
|---|---|---|---|
| Priority: | major | Milestone: | Promot 0.8.1 |
| Component: | PromotGuiVizEdit | Version: | 0.8.0 |
| Severity: | fatal | Keywords: | |
| Cc: |
Description
The renaming of an element causes the generation of an new (default) element at the origin and ProMoT looses the old connections. As a first step the modeler should be prevented from renaming connected elements in the gui.
Change History (5)
comment:1 Changed 17 years ago by mirschel
- Component changed from Promot to PromotGuiVizEdit
comment:2 Changed 17 years ago by steinmet
- Milestone set to Promot 0.9
- Version set to 0.8.0
comment:3 Changed 17 years ago by steinmet
- Status changed from new to assigned
comment:4 Changed 17 years ago by rempel
- Milestone changed from Promot 0.9 to Promot 0.8.1
- Resolution set to fixed
- Status changed from assigned to closed
comment:5 Changed 17 years ago by rempel
Connected elements can be renamed now, links are updated. Renaming terminals works in the module but may break connections outside, so make sure that all required terminals are present (otherwise invalid connections are marked in the container module). Geometry information of all edges in all links connected with the renamed element are lost (see ticket #112). Concurrency problems combined with the lazy update from lisp leads to the problem that the new slot is not visible for the lisp side until some time has passed (concurrently running threads prevent the flush from java model -> lisp, maybe some updates in lisp are still missing?) Usually one can use the slots after some time has passed, but there is no mechanism to signal that the slots are "ready".
Connected elements can be renamed now, links are updated. Renaming terminals works in the module but may break connections outside, so make sure that all required terminals are present (otherwise invalid connections are marked in the container module). Geometry information of all edges in all links connected with the renamed element are lost (see ticket [112]). Concurrency problems combined with the lazy update from lisp leads to the problem that the new slot is not visible for the lisp side until some time has passed (concurrently running threads prevent the flush from java model -> lisp, maybe some updates in lisp are still missing?) Usually one can use the slots after some time has passed, but there is no mechanism to signal that the slots are "ready".