Topic: Problem with displaying elements

A problem that already occurred when editing the pneumatic symbols is still there.

If the element is in the form of a horizontal tank, it will already be displayed incorrectly
in the preview and also in the plan page. With the pneumatic symbols I have to solve the
fact that I inserted a component from an old library. I was not allowed to change the
component, otherwise the error occurred again.

Maybe you could take a look, but there's no rush.

Post's attachments

Attachment icon Bildschirmfoto_2023-01-20_17-13-38.png 122.93 kb, 23 downloads since 2023-01-21 

Re: Problem with displaying elements

This element are a wrong hostspot, just open in editor and save again.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problem with displaying elements

Nothing changes if I open the component with the component editor and then save it again.

Re: Problem with displaying elements

Maybe send element here?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problem with displaying elements

It is contained in the 20_logic.7z file:
https://qelectrotech.org/forum/viewtopic.php?id=2385

20_logic/2020_flow_chart/202010_flow_chart/20201000_start.elmt
20_logic/2020_flow_chart/202010_flow_chart/20201001_end.elmt

6 (edited by plc-user 2023-01-21 23:51:03)

Re: Problem with displaying elements

scorpio810 wrote:

This element are a wrong hostspot, just open in editor and save again.

You are perfectly right, Laurent!

Corrected the files from packed file with QET_ElementScaler and added here as *.tar.gz

Post's attachments

Attachment icon 20_logic.tar.gz 35.58 kb, 52 downloads since 2023-01-21 

Re: Problem with displaying elements

Vbxler wrote:

Nothing changes if I open the component with the component editor and then save it again.

You are right, too, Vbxler!

The definition-line of your Start-Element has these values:

hotspot_y="14" height="40" width="90" hotspot_x="45"

and shows the graphical errors.
The corrected version of the file from QET_ElementScaler has these values:

hotspot_y="15" height="40" width="110" hotspot_x="55"

and shows perfect graphics.

When I re-open the corrected file in Element-Editor and save it again, the false values are written to file again.
It seems that the calculation of hotspots and size of the element is broken in Element-Editor at the moment...

Re: Problem with displaying elements

Hotspot miscalculated the rounding of the arc, a workaroud is to add 2 invisible little line on the two arc center...for the moment.

Post's attachments

Attachment icon 20201000_start.elmt 3.31 kb, 55 downloads since 2023-01-22 

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

9 (edited by plc-user 2023-01-22 11:26:12)

Re: Problem with displaying elements

I use the same code in QET_ElementScaler:

    // calculation taken from QET-sources:
    int upwidth = ((width/10)*10)+10;
    if ((width%10) > 6) upwidth+=10;

    int upheight = ((height/10)*10)+10;
    if ((height%10) > 6) upheight+=10;

Just a thought, Laurent:
Can it be that ARCs aren't taken into account for calculating Element's size?
The other graphical elements seem to be used for calculating size...

Re: Problem with displaying elements

Yes, I think it does not calculate the extreme position of the ARC primitive, is the case if we stretch the arc into an ellipse :
https://github.com/qelectrotech/qelectr … e.cpp#L405
https://github.com/qelectrotech/qelectr … t.cpp#L249

Ctrl + A for selected all parts, is wrong!
https://download.qelectrotech.org/qet/forum_img_2/hotspot_calcul.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problem with displaying elements

Hmm! ok on the 0.7 AppImage, not on 0.8 AppImage ...
https://download.qelectrotech.org/qet/forum_img_2/hotspot_calcul_0.7.png

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

12 (edited by plc-user 2023-01-22 12:22:29)

Re: Problem with displaying elements

Maybe here?

https://github.com/qelectrotech/qelectr … c.cpp#L165

/**
 * @brief PartArc::sceneGeometricRect
 * @return the minimum,
 * margin-less rectangle this part can fit into in scene coordinates.
 * It is different from boundingRect() because it is not supposed
 * to imply any margin,
 * and it is different from shape because it is a regular
 * rectangle, not a complex shape.
 */
QRectF PartArc::sceneGeometricRect() const
{
    return mapToScene(QetGraphicsHandlerUtility::rectForArc(m_rect, m_start_angle/16, m_span_angle/16)).boundingRect();
}

... or at least in that file?

Re: Problem with displaying elements

I think it's here:
https://github.com/qelectrotech/qelectr … 3ea8c55daf

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

14 (edited by plc-user 2023-01-22 19:59:38)

Re: Problem with displaying elements

Yes, I think you are right, Laurent!
In the function starting here:
https://github.com/qelectrotech/qelectr … y.cpp#L189
The ELSE branches ensure that only the start and end points of the ARC are used for the calculation of the surrounding RECT size. In this case, this is counterproductive!

Is there anything against always assuming an "ellipse" for the determination of the surrounding rectangle?
(But please don't expect me to adopt this today: Before I have managed to get familiar with QT-programming and the IDE it will be Christmas again... nomicons/wink)

Another thought for ARCs:

For the determination of the surrounding rectangle, it might be easier to limit the number of case distinctions. For this it might be helpful if (at the latest when saving the XML file) we always keep the angles of the ARC in the positive range?
These arcs are identical:

Start = -10 / Angle =  30
Start =  20 / Angle = -30
Start = 350 / Angle =  30

For case distinctions in internal calculations, however, it might help...

Implemented normalisation for start and angle of ARCs in QET_ElementScaler and just released a new version on github.
Maybe it helps...

Re: Problem with displaying elements

I will take a look soon about this problem

Développeur QElectroTech

Re: Problem with displaying elements

For QET_ElementScaler I now use this (mathematically correct) determination for the min-max values of an elliptical arc:

    // calculate points on ellipse-circumference:
    // x = a ⋅ cos(t)
    // y = b ⋅ sin(t)
    // with t = 0 .. 2*pi = ([0 .. 360]/360)*2*pi
    // for ARC with x- and y-offset in a loop from Start to (Start+Angle):
    for (int i = Start; i <= (Start + Angle); i++){
        double val_x = X + (Width/2) * (1 + cos((i%360)/360.0*2*pi));
        double val_y = Y + (Height/2) * (1 - sin((i%360)/360.0*2*pi));
        XYMinMax.add(val_x, val_y);
    }

This may be too time-consuming for the productive version of QET, but here I allowed that "luxury-version"...   nomicons/wink
Now available here: https://github.com/plc-user/QET_ElementScaler

Re: Problem with displaying elements

Fixed,
I use a missile for kill a fly......

Développeur QElectroTech

Re: Problem with displaying elements

Thanks for your efforts, it works now!