Thanks, that was really helpful and I probably wouldn't have found it on my own. Note that the associated readme.md file is misleading.

I'm interested in a simple example of how to initialize and then use the omc_OpenModelicaScriptingAPI_* functions in this dll in order to build an entirely stand-alone application that can interact with Modelica objects. Specifically, there's the matter of properly obtaining the threadData_t object needed by all of these functions and how to initialize any logging and error handling behavior(s).

The API defined in OpenModelicaScriptingAPIQt.h I find interesting because it wraps the above methods in a way that I'll want to do similarly in C++. Any examples for how to use this API in a standalone mode?

I haven't found any simple examples in the source distribution. Thanks in advance for any pointers.

Hey folks... I was experimenting with referencing an SVG file in an bitmap icon annotation for an object and it appeared in OMEdit! All of the documentation that I've seen seems to indicate that SVG is not supported:

The  supported  file  formats  include PNG, BMP and JPEG, other supported file formats are unspecified.

What should I make of this? I would much prefer to specify images in SVG rather than via a true bitmap. Can I continue to rely upon this undocumented "feature"?

I was surprised to discover that a parameter variable's bounds (min/max) are not enforced when a user changes its value via the UI dialog box. It isn't even enforced when checking the model. It appears to be enforced only when the model is simulated.

I understand that the bounds need to be checked every time the variable is set during simulation, but I cannot understand why constant parameter values are not checked when a dialog box is being closed or when the model is checked. Perhaps this is another improvement that would happen with the new front end?

That said, there's already a certain amount of parsing that is happening to verify that a numeric literal value entered into the dialog box conforms to a valid integer or real syntax. At that point it is trivial to convert to a number (if it is a constant), and there's very little time required to test against constant min/max values.

As a new OpenModelica user and model designer, I'm repeatedly loading and unloading a library containing the component parts of a new library within a single instance of an OMEdit session. Once loaded, the only thing I'm doing with that model is to view/modify the various component parts graphically and textually and experimenting with dialog boxes representing component parameter dialog boxes.

After a while, OMEdit eventually exits unexpectedly or more rarely, just hangs. Is there some sort of logging that I can enable that would provide a clue to the source of these  problems so I can report them back to OpenModelica?

Thanks for clarifying this as well as the quote from the spec document. It is indeed unfortunate and I think an oversight that these types cannot be referenced outside of graphical annotations in order that their values can be set from variables outside of those annotations. This was how I was going to parameterize and factor different subclasses of model components with slightly different style options. Doing so would also allow simplification of many of the object definitions within the Modelica library.

Thanks for the reply.

My example doesn't exhibit the full extent of the problem. The definition of Color in Modelica.Mechanics.MultiBody.Types.Color must be a re-declaration of the color type definition used in the graphical annotations: I say that because there are no other similar definitions for other types of graphical attributes (eg the FillPattern enumeration) in the Modelica library.

1)  Re-declarations of the basic Color type used in graphical annotations as such this (when it works) isn't the best solution: DRY and all that. What would happen if the graphical annotation color definitions decide to add an alpha channel?

2) I've tried similarly re-declaring the FillPattern enumeration type using the same names and ordering as the enumeration as described in various bits of documentation. This causes other semantic errors. Alternatively, declaring an enumeration with the type name MyFillPattern (and same FillPattern enumeration names and values) and then using those values within graphic annotations results with the behavior of FillPatern.None regardless of which MyFIllPattern value I use.  Either workaround (even if they did work) violates DRY.

So either I'm misunderstanding how to correctly reference the real Color and FillPattern types outside of graphical annotations or they just aren't available outside of the graphic annotation context. If it is the latter case, then I think this is a language deficiency since it means graphic annotation style values cannot be cleanly obtained from variable values  that are defined within a class as per the example because those type names cannot be referenced.

I sort-of understand this decision, but it has removed something important for novices. Perhaps there could be an OMEdit option that enforces connection consistency checking for newbies like me or be disabled for more experienced users? The mentioned new faster front-end sounds promising for a number of reasons related to some other of my issues as well, but it doesn't promise a solution for this particular problem nor do I see when it may be realized.

Hey folks. Here's something I'm puzzling over. Inside a graphical or icon annotation, one can reference type names like Color and FillColor, eg FillColor.None. However, I cannot seem to be able to reference these type names outside of the context of an annotation. For example:

block TestColorReference
  constant Color blue = {0,0,255};
end TestColorReference

Manually checking this model in OMEdit yields the following errors:

[1] 08:57:26 Translation Error
[TestColorReference: 2:3-2:34]: Class Color not found in scope TestColorReference.

[2] 08:57:26 Translation Error
Error occurred while flattening model TestColorReference

I presume I'm missing some sort of appropriate namespace in front of the word Color?

Thanks for the explanation, that helps.

Unfortunately, a novice (like me) building a model using OMEdit is going to proceed by dragging a bunch of components into a new model and then create connections. Unless one actually checks the model each time after a connection is made, all connection errors are going to be unrecognized until such time that the model is manually checked or attempted to be simulated.  Prohibiting improper connections in the graphical editor in the first place  would make for a far better experience than the current behavior. Further, if a model is created in OMEdit with improper connections, even double clicking its icon within a library will show it in the OMEdit canvas (is this not instantiation?) but any connection errors are not flagged by this operation.

In short, I'm not able (using OMEdit) to prohibit the connection of objects of different underlying types nor the ability to prohibit the connection of inputs to inputs nor outputs to outputs.

Here are the details.

The graphic annotations aren't included in the code below as they don't really matter (unless you're trying to actually demonstrate the behavior in OMEdit, I can supply an example if necessary)... I think this is mostly a misunderstanding on my part, and thanks for bearing with me.

Let's suppose that I define 2 blocks called C1 and C2...

  block C1
    ... a bunch of variables defined here (some of which may be other class instances)
  end C1

  block C2
    ... a bunch of variables defined here different from C1 (some of which may be other class instances)
  end C2

Then I define 2 pseudo-connector classes each of which uses the above. These classes/blocks are defined in order to provide icon graphics for each (which are not included here)...

  block C1Connector
    C1 class1Entity;
  end C1Connector;

  block C2Connector
    C2 class2Entity;
  end C2Connector;

Now I declare the real connector objects:

  connector C1In = input C1Connector;
  connector C1Out = output C1Connector;
  connector C2In = input C2Connector;
  connector C2Out = output C2Connector;


Finally, I create a couple of simple component blocks that include all 4 of these connectors...

  block Component1
    C1In c1In;
    C1Out c1Out
    C2In c2In;
    C2Out c2Out
  end Component1

  block Component2
    C1In c1In;
    C1Out c1Out
    C2In c2In;
    C2Out c2Out
  end Component2
   
My hope is that I am not able to interconnect a C1* connector to a C2* connector, nor a *In connector to a *In connector nor a *Out connector to a *Out connector. Unfortunately, I am able to do so.

Now, I drag these instances of Component1 and Component2 onto the OMEdit canvas. Selecting the OMEdit connect button, I can now click on any connector shown for Component1 and connect it to any connector of Component2. Why should I be able to connect across the connector type classes that also allow input-input and output-output connections?

What am I missing here?

  Thanks for the reply Adrian. Is this something that I should be entering as a bug report?  Could you please point me to information about the new front end (what it is, when it is supposed to be available)?

Here's the source code for the Modelica.Blocks.Interfaces.RealOutput connector (with Documentation html removed so as not to screw up the source displayed in this post):

connector RealOutput = output Real "'output Real' as connector" annotation (
  defaultComponentName="y",
  Icon(
    coordinateSystem(preserveAspectRatio=true,
      extent={{-100.0,-100.0},{100.0,100.0}}),
      graphics={
    Polygon(
      lineColor={0,0,127},
      fillColor={255,255,255},
      fillPattern=FillPattern.Solid,
      points={{-100.0,100.0},{100.0,0.0},{-100.0,-100.0}})}),
  Diagram(
    coordinateSystem(preserveAspectRatio=true,
      extent={{-100.0,-100.0},{100.0,100.0}}),
      graphics={
    Polygon(
      lineColor={0,0,127},
      fillColor={255,255,255},
      fillPattern=FillPattern.Solid,
      points={{-100.0,50.0},{0.0,0.0},{-100.0,-50.0}}),
    Text(
      lineColor={0,0,127},
      extent={{30.0,60.0},{30.0,110.0}},
      textString="%name")})));

The diagram for this connector displays fine. If you change the lineColor value in the Diagram's Text to the word Black, the diagram disappears. However, if you use the word textColor instead of lineColor (and leave the value as the word Black) the diagram reappears as expected. Note that the diagram looks fine if you use the word lineColor or textColor so long as its value is an actual color tuple (eg {0,0,0}).

Coming from the graphics world, I never understand why colors for such graphic languages as this define RGB color models in such a way that is so tied to the underlying (hardware) color model. A more abstract RGB color model less tied to the implementation would use real numbers for each primary component in the range [0,1].  Adding additional fixed names for the common colors (primaries, secondaries) like Red would be a welcome addition.

Hi folks.  I would like to create a class/block that has an annotation that defines icon/drawing graphics and then have subclasses/subblocks slightly modify the graphics. So for example:

block BaseGraphic
  constant Color color = {255,0,0};
  annotation
  (
       Icon
      (
        coordinateSystem
        (
          extent={{-100,-100},{100,100}},
          initialScale=0.2
        ),
        graphics=
        {
          Polygon
          (
            lineColor=color,
            fillColor=color,
            points={{-100,100},{100,0},{-100,-100}}
          )
        }
      )
  )
end BaseGraphic;

block YellowGraphic
  extends BaseGraphic(color={255,255,0});
end YellowGraphic;


When I instantiate a YellowGraphic object, the color does not change to yellow. It seems that the inherited annotation in YellowGraphic is not evaluated in the context of YellowGraphic and the color remains red. I've tried redeclaring the constant color in YellowGraphic as well with the same results.

How do I go about doing so? I really don't want to repeat what is a much more complicated graphic definition than shown in the example above in the 6 derived classes/blocks I want to define.

Thanks in advance.