Opened 10 years ago

Closed 10 years ago

#2992 closed defect (fixed)

OMEdit: Connection coordinates faulty on x- and y-axis

Reported by: Jan Kokert Owned by: Adeel Asghar
Priority: low Milestone: 1.9.2
Component: OMEdit Version: trunk
Keywords: Snap to grid on axis Cc:

Description

Today, I observed another minor bug in OMEdit.
If you place connection end points between components onto to the x or y-axis by moving the component, the snap-to-grid values are not zero, but “very small”.
An unhandled div/0 may be a candidate, but I can't explain exactly why this is faulty:
point.setX(stepX * floor((point.x() / stepX) + 0.5));

I figured out, that the error mainly occurs on axes, which are orthogonal to the direction, which is implied by the component. Here an example:
1.) Place two resistors at (-20|20) and (20|20).
2.) Move the right resistor to (10|20). The resulting annotation will be
annotation(Line(points = {{-10, 20}, {-1.49012e-07, 20}}, color = {0, 0, 255}));
3.) If you move the right resistor to (20|0) everything is fine.

The defect seems to be related to #2477. I opened a separate ticket, because graphically the snapping works well. (Sorry, for finding again and again errors in OMEdit...)

Change History (10)

comment:1 by Jan Kokert, 10 years ago

Component: UnknownOMEdit
Milestone: Future1.9.2
Owner: changed from somebody to Adeel Asghar

comment:2 by Adeel Asghar, 10 years ago

Why sorry.....actually I should thank you for finding these issues. Since I am working on it nowadays so its easy for me to fix issues quickly.

I think I know what the problem is. I will try to fix it.
BTW, we can never be a candidate of division by zero since getHorizontalGridStep() makes sure that stepX can't be zero.

comment:3 by Adeel Asghar, 10 years ago

The problem is a little bit more complicated then what I thought. Actually the start and end point of connections are not snapped to grid and they shouldn't be. If I snap them to grid then the connection line might start slightly misaligned from the port.

For example in the above case of resistor we take the center of port for the connection start and end point and the port can be anywhere in the view port (i.e it is not necessarily snapped to grid).

comment:4 by Adeel Asghar, 10 years ago

Even Dymola doesn't care about grid size in this case. Dymola just seems to call round in this case.

comment:5 by Adeel Asghar, 10 years ago

In r23442 I have rounded the start & end points of the connection. You won't get any fractional values in the text but connection line can appear slightlyyyyyy misaligned from the center of the start/end port.

I can't think of a better solution right now.

in reply to:  2 comment:6 by Jan Kokert, 10 years ago

Replying to adeas31:

Why sorry.....actually I should thank you for finding these issues. Since I am working on it nowadays so its easy for me to fix issues quickly.

On the one hand I'm just happy that all these issues are corrected so quickly, on the other hand I guess that there is still much work to do... So I will continue to open ticket and cause work :)

Version 0, edited 10 years ago by Jan Kokert (next)

comment:7 by Jan Kokert, 10 years ago

The issue with fractional values is fixed in r23442 from my point of view. If no errors (div/0) occures in the background be can close this ticket.

in reply to:  7 comment:8 by Adeel Asghar, 10 years ago

Replying to janK:

The issue with fractional values is fixed in r23442 from my point of view. If no errors (div/0) occures in the background be can close this ticket.

No. There are still some issues left. Since we added the snap to grid later in the project so there are still some places where non-snapped values are set which messes up the code. I am trying to fix it.

Btw I am going to change the roundPoint() introduced in r23442 so that it will not round the values which are multiple of 0.5,

QPointF GraphicsView::roundPoint(QPointF point)
{
  qreal divisor = 0.5;
  qreal x = (fmod(point.x(), divisor) == 0) ? point.x() : qRound(point.x());
  qreal y = (fmod(point.y(), divisor) == 0) ? point.y() : qRound(point.y());
  return QPointF(x, y);
}

comment:9 by Adeel Asghar, 10 years ago

I think its fixed now in r23450.

Feel free to create tickets if you find any issue. Lets make OMEdit a better Modelica editor.

comment:10 by Adeel Asghar, 10 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.