Bug #5630
Standard selection view property value editing fixes
| Status: | Closed | Start date: | 2015-01-22 | |
|---|---|---|---|---|
| Priority: | 4 | Due date: | 2015-01-22 | |
| Assignee: |  Tuukka Lehtonen | % Done: | 100% | |
| Category: | Selection view | Spent time: | - | |
| Target version: | 1.18.1 | |||
| Release notes: | * Fixed component type editor to set proper L0.HasValueType properties for values when user modifies a state property's type in the user component configuration editor.
* Fixed org.simantics.selectionview.All to set a proper L0.HasValueType value for newly created literal values if necessary (calculated value type differs from the asserted one) * Fixed PropertyInfoRequest to resolve requiredValueType from L0.HasRange + L0.HasValueType definitions if that is the only thing that is defined for a property relation. |
|||
| Tags: | db, selection, edit | |||
| Story points | - | |||
| Velocity based estimate | - | |||
| Release | Simantics 1.18.1 | Release relationship | Auto |
Description
There are several problems in the standard selection view property editing procedure:
- org.simantics.selectionview.All may attach an invalid L0.HasValueType literal to a newly created literal value if the edited property datatype contains annotations (e.g. unit="mm") and is of another type than Double.
- When Development.DEVELOPMENT = true, the following problems surfaced:
- ComponentTypeViewer/ComponentTypeCommands contains a bug that leaves the MOD.MonitorValue instances created for StateProperties with the initial L0.HasValueType values even if the user edits the type of a state property. Currently the HasValueType of that monitor value literal will always stay as Double which is invalid.
- PropertyInfoRequestin does not resolve requiredValueType from L0.HasRange + L0.HasValueType definitions if that is the only thing that is defined for a property relation.
- MOD.contextualHelpId and MOD.Functions.modificationTimeTextLong are missing RequiresValueType definitions.
Associated revisions
- Fixed ComponentTypeViewer/ComponentTypeCommands to also set MOD.MonitorValue L0.HasValueType value when the user modifies a state property's type in the user component configuration editor.
- Fixed org.simantics.selectionview.All to set a proper L0.HasValueType value for newly created literal values if necessary (calculated value type differs from the asserted one)
- Fixed PropertyInfoRequestin to resolve requiredValueType from L0.HasRange + L0.HasValueType definitions if that is the only thing that is defined for a property relation.
- Added missing L0.RequiresValueType definitions for MOD.contextualHelpId and MOD.Functions.modificationTimeTextLong.
refs #5630
History
#1
Updated by Tuukka Lehtonen about 3 years ago
- Description updated (diff)
#2
Updated by Tuukka Lehtonen about 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
#3
Updated by Tuukka Lehtonen about 3 years ago
- Status changed from Resolved to Closed
#4
Updated by Tuukka Lehtonen almost 3 years ago
- Tags set to selection, db, edit
- Release notes set to * Fixed component type editor to set proper L0.HasValueType properties for values when user modifies a state property's type in the user component configuration editor. * Fixed org.simantics.selectionview.All to set a proper L0.HasValueType value for newly created literal values if necessary (calculated value type differs from the asserted one) * Fixed PropertyInfoRequest to resolve requiredValueType from L0.HasRange + L0.HasValueType definitions if that is the only thing that is defined for a property relation.