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 , 10 years ago
Component: | Unknown → OMEdit |
---|---|
Milestone: | Future → 1.9.2 |
Owner: | changed from | to
follow-up: 6 comment:2 by , 10 years ago
comment:3 by , 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 , 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 , 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.
comment:6 by , 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 :)
follow-up: 8 comment:7 by , 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.
comment:8 by , 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 , 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 , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 thatstepX
can't be zero.