Problem with Coming arrow and mixed text

https://qelectrotech.org/forum/viewtopi … 162#p17162 ?

Thank you for the link to the related topic and the suggestion about the “Do not store the label of the items in the copy paste” option.
I tried both with the checkbox enabled and disabled, but the behavior remains the same – after copying, the mixed text is still cleared and the text box is moved to a different position.

I have the latest version of QElectroTech installed (installed yesterday).
If it would help, I can prepare a short video showing the issue, so the exact steps and result can be clearly seen.
Jiri

Related topic:  Text offset when copying
https://qelectrotech.org/forum/viewtopic.php?id=2974

Subject: Replace object with xref to another folio
https://qelectrotech.org/forum/viewtopic.php?id=3002

Thank you all for your responses and the time spent on this topic. I can see that a similar issue, just under a different name, already exists and that finding a solution is not simple and does not yet exist.
During my testing, I noticed that when I create a link and move it with the mouse, sometimes it works, but most of the time it does not. I’m considering whether a temporary workaround could be to keep the alignment to the left side and simply increase the offset – this seems to work flawlessly.
I would be very happy if a permanent solution could be found, and I truly appreciate the great work being done on this program.

However, there is still the issue that after pressing Ctrl + C, the labels on the links appear to “disappear” – their alignment and position change, so they are no longer visible in their original place, even though the links themselves remain functional and connected. Would it be possible to address this so that the label positions remain visible after copying?

Jiri

However, there is still the issue that after pressing Ctrl + C, the labels on the links appear to “disappear” – their alignment and position change, so they are no longer visible in their original place, even though the links themselves remain functional and connected. Would it be possible to address this so that the label positions remain visible after copying?

For reference, I am using the latest version of QElectroTech (installed yesterday) and fully updated Windows 11:

QElectroTech V 0.100.0-dev
Sestavení: GCC 11.5.0
Built with Qt 5.15.17 - x86_64 - Date : Aug 14 2025 : 15:37:12
Run with Qt 5.15.17 using 8 thread(s)
CPU : NAME 11TH GEN INTEL(R) CORE(TM) I7-1165G7 @ 2.80GHZ
RAM Total : 65 GB
RAM Available : 46 GB
GPU : VideoProcessor NVIDIA GeForce MX350 Intel(R) Iris(R) Xe Graphics Family
GPU RAM : RAM Total : AdapterRAM 2147483648 2147479552 B
OS : winnt - x86_64 - Version : Windows 11 Version 2009 - Kernel : 10.0.26100
*** Qt screens ***
( 1 : 2560 x 1600 )
( 2 : 3840 x 2160 )
( 3 : 3840 x 2160 )

I just did a little testing, and it looks like the '/' sign is the problem.
Could you please delete the '/' in the comming arrow and then test again.

Ja, habe ich auch gerade festgestellt. Und damit das ganze noch etwas komplizierter wird,
es ist ein Unterschied ob ich z.B. den '/' im Elementeditor oder im Diagram Editor ändere.
Ich schau mir das an, vielleicht finde ich ja eine Lösung.

Yes, I just realized that too. And to make things a little more complicated,
it makes a difference whether I change the '/' in the element editor or in the diagram editor.
I'll take a look into it, maybe I'll find a solution.

Thanks for the tip

Thank you for the quick response and for starting to analyze the issue so promptly.
I can confirm that after removing the slash character /, the behavior has indeed improved. I have been using the slash because we commonly use it in our work in EPLAN, and visually it is ideal for us – for example, a dash looks unsuitable when combined with the plus sign for a positive conductor.
However, when using right alignment, the entire block still shifts. It would be great if the slash could somehow be retained, or if another character could be found that behaves correctly and also looks visually appropriate.
I am happy to continue testing and verifying any adjustments to help find a permanent solution. Once again, thank you for the great work and user support.
Jiri

Ich habe gerade einen pull request gemacht. Die Positionierung der Texte sollte jetzt passen. Wenn eine neue QET-Version
rauskommt könnt ihr ja reichlich testen.

@Laurent
Das / Zeichen hat in diesem Fall keine funktionale Bedeutung, es ist nur ein Char. Jedes andere Zeichen hätte auch das
Problem verursacht. Der Fehler war einfach nur, das ich bei Composite Text mit nur einer Variable getestet habe. Dadurch
habe ich nicht bemerkt das für Composite Text mit mehren Variblen oder mit user Text ein anderes handling nötig ist.

I just made a pull request. The text positioning should be correct now. You'll have plenty of time to test it when a new QET
version comes out.

@Laurent
The / character has no functional meaning in this case; it's just a character. Any other character would have caused the
problem. The mistake was simply that I was testing composite text with only one variable. As a result, I didn't realize that
different handling is required for composite text with multiple variables or with user text.