Search options (Page 1 of 4)

Was ist ein Kontaktkamm? Meinst du Kontaktspiegel?
Wenn du den Kontaktspiegel meinst, den kannst du allein nicht frei bewegen.
Wie der Kontaktspiegel positioniert wird, wird in den Projekteigenschaften unter
Querverweise festgelegt.
Bewegen kannst du den Kontaktspiegel nur mit dem Element, oder als Bestandteil
vom BMK(Label). In den Einstellungen kannst du unter 'Position' mit der Einstellung
'Unter dem Betriebsmittelkennzeichen' den Kontaktspiegel unter dem BMK anzeigen
lassen. Für das eigentliche BMK nutze ich den Composite Text mit der Label-Variablen,
und mit dem eigentlichen BMK-Text positioniere ich den Kontaktspiegel so, wie ich den
brauche.
Hoffe es hilft Dir.

Thanks for the tip

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.

Hallo plc-user

Vorweg: Die Änderung im Code kann den weißen Rand nicht weg machen !!!
Aber ich denke er kann helfen diesen Rand zu verhindern.

Vielen Dank für die Hinweise aus deinem letzten Post. Das mit "Nur eine Potenzialbeschriftung je Folie anzeigen" hatte ich
noch gar nicht bemerkt. Das mit der Conductorbeschriftung ist nicht unbekannt, da hat sich blacksun schon mal Gedanken
drüber gemacht(siehe conductortextitem.cpp ab Zeile 132).

Wenn man sich die XML von betroffenen .qet Dateien anschaut, erkennt man das die Conductoren teilweise negative
Koordinatenwerte (x oder y) haben. Auch in deiner Verweise.qet ist das der Fall. Ändert man die Koordinaten einfach auf Null,
ist der weiße Rand weg. Das war mein Ansatz bei der Suche nach dem Fehler. Diese negativen Koordinaten entstanden
beim kopieren an genau dieser Stelle im alten Code. Der neue Code erzeugt keine negativen Koordinaten mehr,
er ändert sie aber auch nicht.
Grundsätzlich wird die Position des Conductors nicht über Koordinaten bestimmt, sondern durch die beiden Terminals, die
der Conductor verbindet.

Wie gesagt, ich denke das ist eine Teillösung  um den Fehler zu beheben. Es gibt sicher noch einige
offene Fragen zu diesem Fehler, und ich werde an dem Problem dran bleiben.

Aber unabhängig vom Problem mit dem weißen Rand, denke ich das der Code  besser ist, weil er die Conductoren über die Terminals setzt und nicht über Koordinaten.

@plc-user
Danke für deine Hinweise. Es ist genau wie du es beschreibst.

QET benutzt beim Kopieren  den Einfügepunkt des  beschrifteten
Textfeldes, und nicht den Einfügepunkt des originalen leeren
Textfeldes. Dadurch wandert der rechtsbündige Text immer nach links.
Also muss nach dem Kopieren/Einfügen wieder der ursprüngliche Einfügepunkt
hergestellt werden. Funktioniert auch auch bei einzelnen Elementen,
aber leider noch nicht beim Kopieren eines selektierten Bereiches
mit Elementen und Verbindern.

Ich musste beim Testen feststellen, daß beim kopieren eines markierten
Bereiches (mehrere Elemente und Conductors) der Fehler nach wie vor
auftritt. Einzelbauteil funktioniert. Das würde ich gerne noch lösen bevor
ich einen Pull-Request mache.

Hi,
das ist ein bekanntes und auch schon älteres Problem beim kopieren
von Slave- und Verweiselementen mit rechts- und
mittigbündigen Text.
Ich denke ich habe das Problem im Code erkannt und werde die Tage mal einen
Pullrequest machen.

No, currently there is no way to set the grid in the ElementEditor

Das ist nicht möglich.
Die eigenen Variablen sind nur für die Schriftfeder.

Was stellt das klar???
Du willst das was in den Leitereigenschaften im Feld "Text" steht im Folienverweis nutzen, richtig?
Das geht nicht direkt. Aber du Kansst zB. den Namen in das Feld Funktion schreiben und dann mit
der Variablen "%wf" in der Textformel den Namen in das Feld Text bringen. Und im Folienverweis
hast du, wie du ja schon festgestellt hast, auch Zugriff auf das Feld "Funktion."

There's a little help. When the mouse pointer hovers over the text, a tooltip appears with a reference to the Shift key. This was added recently, so it might not be included in your version yet. It works in the latest Linux app image, but I can't test it on Windows right now.
The main reason for adding the Shift key was that the text would often jump to the next grid point when clicking, and you had to move back the text each time. That can not happen anymore.
Another improvement, especially for small elements, is that when you move them, you simply grab the element and move it, regardless of whether the mouse is over the text or not. But there are also a few problems, as you have already noticed.
In my opinion, there are two options.
1. We work with a second key, currently the SHIFT key. Advantages: The text no longer jumps, and when you move the element, you don't have to pay attention to where you grab it. Disadvantage: For any actions with the text, it must first be selected with SHIFT and the mouse button. Assuming the text moves in increments in the grid as before, we need a second key for moving in small increments (the CTRL key doesn't work, as it conflicts with the view mode). Further corrections need to be made, e.g., in GroupBox
2. We'll restore the previous state. There's another solution for jumping text. Disadvantage: When moving elements, you have to be careful not to grab any text when you touch the element.
What do you think?