Bug #5630

Standard selection view property value editing fixes

Added by Tuukka Lehtonen over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:2015-01-22
Priority:4Due date:2015-01-22
Assignee:Tuukka Lehtonen% Done:

100%

Category:Selection viewSpent 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-
ReleaseSimantics 1.18.1Release relationshipAuto

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

Revision 30843
Added by Tuukka Lehtonen over 2 years ago

  • 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 over 2 years ago

  • Description updated (diff)

#2 Updated by Tuukka Lehtonen over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

#3 Updated by Tuukka Lehtonen over 2 years ago

  • Status changed from Resolved to Closed

#4 Updated by Tuukka Lehtonen over 2 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.

Also available in: Atom PDF