Page History

...

• when to extrapolate/interpolate
• the component needs to know which decorator is a TimeDecorator.
  

...

• See discussion in chapter 4 on decorators.

2.5 GUI

The Gui is quite on its way. To be done:

...

values = providingOutputItem.GetValues(consumerThatIsAsking);

1. Should we introduce a boolean argument that indicates whether the component should run in a pull mode (like

...

1. in OpenMI 1.4) or in loop mode?
2. Discuss component operation mode here comment from Peter Gijsbers need to be discussed
3. When we get loops in the compositions - we have to tell which component will be first! In the new GUI, we will let the user indicate the 'Start up component'.
    

...

Discussion/Conclusion part 2: We decided to let the LinkableComponent have a propery: CascadingCallsDisabled.
The default is false, indicating that the component is running in Pull Driven mode (there will be a cascade of update() calls. This Pull Driven mode has to be supported by every component.
If set to true, the component is expected to run Update()-step by Update-Step(), controlled by some outer world (which may be another component). If the component does not support this Update() by Update() way of running, it will throw an Exception when CascadingCallsDisabled

...

= true is called;

1. "string Validate()" / "bool IsValid(IExchangeItem item)" / "IsAvailable()", etc.
   • to be reviewed at this meeting

1. The Timezone issue has to be re-adressed. According to Adrian it is not doing what we expected.

1. Decorator issues:
   • Do we need to recognize the type of decorator (time, space, SI-conversion)?
   • Do we want to support 3th-party decorators indeed?
     Discussion/Conclusion part 1: We will add an Update() method to the OutputDecorator. The linkable component calls this Update() on all its decorators at the end of its own Update(). This actually is completely the same as what happens in the current 1.4 Wrapper: after IEngine.PerformTimeStep the wrapper updates the buffers.

• Decorator issues, GUI:
  • How to support the end user, when "chaining" decorators? Taken care of, see section 2.5

• Decorator issues, other:

...

• to be reviewed at this meeting

...

• The Timezone issue has to be re-adressed. According to Adrian it is not doing what we expected.

• Decorator issues:
  • Do we need to recognize the type of decorator (time, space, SI-conversion)?
  Do we want to support 3th-party decorators indeed?
  • Is is useful to let the component have a property OutputDecorators, containing the list of already created decorators?How to support the end user, when "chaining" decorators?

• IArgument needs a mechanism for identifying the type of argument e.g. File, Path, int double etc Very usful for providing customised GUI functionality
  • Adrian's proposal is below

    Code Block
    java java
    namespace OpenMI.Standard { public enum EArgType { String = 0, // default Bool, Int, Double, Path, // presummed to exist and accessable FilePath, // presummed to exist and accessable PathNew, FilePathNew, XML, // Rob: can be used together with a schema for complex argument data MIME, // Rob: might be useful to pass in images, or text documents, etc. } /// <summary> /// The IArgument interface defines a key - value pair. If the property ReadOnly is /// false the value is editable otherwise it is read-only. /// </summary> public interface IArgument : IDescribable { /// <summary> /// Type that string value represents and can be converted to /// </summary> EArgType ValueType { get; } /// <summary> /// The key (string) in key-value pair. /// </summary> string Key {get;} /// <summary> /// <para>The value (double) in key-value pair.</para> /// /// <para>If the ReadOnly property is true and the property is attempted to be changed /// from outside an exception must be thrown.</para> /// </summary> string Value { get; set; } /// <summary> /// Defines whether the Values property may be edited from outside. /// </summary> bool ReadOnly {get;} } }

...