Search options (Page 1 of 305)

Hi all,

Following the previous work on terminal name display in cross-references, I've added a new option to disable this feature per xref type, as Achim had recommended.

A new checkbox "Show terminal numbers in Xrefs" (Show terminal names in Xrefs) has been added to the XRef properties widget, in the main display group — so it is available in both Cross and Contacts modes.

When unchecked, terminal names are hidden in all rendering paths:
- drawContact() — Contacts mode (NO/NC/SW symbols)
- fillCrossRef() — Cross mode (NO and NC columns)
- setUpCrossBoundingRect() — Cross mode (bounding rect sizing)

The new boolean property 'showTerminalName' (default: true) is fully persisted in XML and QSettings, so existing project files are not affected (backward compatible).

Also included in the same patch series: a fix for power contact terminal pairing in Contacts mode. The previous alphanumeric sort was breaking consecutive-pair grouping for terminals named L1,L2,L3,T1,T2,T3 — pole 0 was showing L1/L2 instead of L1/T1. Terminal names are now used in declaration order from the element editor; users must declare pairs consecutively (e.g. L1,T1,L2,T2,L3,T3).

Files changed:
- sources/properties/xrefproperties.h
- sources/properties/xrefproperties.cpp
- sources/ui/xrefpropertieswidget.ui
- sources/ui/xrefpropertieswidget.cpp
- sources/qetgraphicsitem/crossrefitem.cpp

Joshua, Achim, plc-user, Kellermorph — thoughts?

crossrefitem: fix terminal name sorting for power contacts

The previous sort used QString::toInt() to order terminal names,
which returns 0 for any string containing a non-numeric prefix
(e.g. "R1", "R2", "L1", "L2"...). This caused undefined sort order
and incorrect pole pairing in the Xref contact mirror.

Example: a 4-pole NC power contact with terminals R1..R8 was
displaying R1/R3, R5/R7, R2/R4, R6/R8 instead of the correct
R1/R2, R3/R4, R5/R6, R7/R8.

Fix: extract the trailing numeric part of each terminal name and
compare prefixes separately. If both names share the same prefix
and both have a trailing number, sort numerically on that number;
otherwise fall back to full string comparison.

This covers all naming conventions: "1"/"2"/"3", "R1"/"R2"/"R3",
"L1"/"L2"/"L3", etc.

Applied in both drawContact() and setUpCrossBoundingRect().

Edit : wrong pictures. done

Additional fix pushed today: crossrefitem: fix SIGSEGV when dropping a power NC contact on the folio

A reproducible crash (SIGSEGV in QRegion::begin) occurred as soon as a power NC slave element was placed on a folio, even before linking it to a master element.

Three bugs were found and fixed in crossrefitem.cpp:

1. m_drawing (QPicture) was never reset between updateLabel() calls.
QPicture accumulates paint commands — calling qp.begin() on an existing QPicture appends to it rather than replacing its content. After several updates (load, move, hover...) the picture became corrupted and crashed on play().
Fix: reset m_drawing = QPicture() at the start of updateLabel().

2. m_drawed_contacts was only initialized to 0 in drawAsContacts(), but not in drawAsCross().
When drawing in Cross mode, fillCrossRef() called drawContact() with an uninitialized m_drawed_contacts value, producing a garbage offset. The NC contact symbol uses drawPolyline() with a sub-pixel Y coordinate (offset+2.5); with a random offset Qt generated an invalid QRegion and crashed.
This explains why NC contacts crashed but NO contacts did not: the NO symbol only uses drawLine() which is more tolerant of bad coordinates.
Fix: add m_drawed_contacts = 0 at the start of drawAsCross().

3. setUpCrossBoundingRect() used QRectF() (null rect) as the reference rect for painter.boundingRect(), which can return invalid dimensions. Additionally, height was accumulated incorrectly: united() + setHeight() doubled the height at each iteration, causing an exponentially growing bounding rect with multiple contacts.
Fix: use QRectF(0, 0, 500, 20) as reference rect and accumulate height and width independently.

Only crossrefitem.cpp was modified.

Is your element a power element?
See my contactor power element.

@Kellermorph:

Yes, it’s a lot of work, but everything is scripted and all I have to do is wait for the machine to finish compiling and packaging it; however, it takes a bit of time, and you need powerful machines that can compile QET in under 90 seconds, like my old Threadripper 3960X with 24 cores and 48 threads. Thank you to everyone who helped me buy this workstation in 2020 through their donations.

-> Workstation build 2020
Funding for a new build machine 2019

FYI, we have now two CI/CD one for snap but in edge channel, and Windows CI/CD github action pushed by me, and we wait to signpath.io mail for valid or cancel signing job before upload Installer, Ready-to-use and MSI to https://qelectrotech.github.io/qelectro … ce-mirror/

By the way I launch my packaging script to packages Debian stable and unstable deb, make PPA Upload, after I launch macOS KVM/Qemu VM for bundle Intel dmg, Open AppImage VM and build new AppImage, I open flatpak VM and build new flatpak.

After I launch my mac Mini M2 for build dmg signed and notarised for macOS Apple silicon, after I launch my Raspery Py 5 for build AppImage for aarch64 Linux.

Built with Qt 5.15.13 - x86_64 - Date : May 22 2026 : 09:36:52 so I pushed PR this night very late, build some packages and go to bed.. now I continu to packages other

QElectroTech V 0.100.1-dev
Compilation : GCC 15.2.0
Built with Qt 5.15.17 - x86_64 - Date : May 23 2026 : 00:14:25

See log and check the version git hash.
You use my PPA or snap, for snap I don't deploy it to stable channel yet.
Or you use my Debian deb repository?

Kellermorph wrote:

I installed the new update that was offered to me via Discover.
I don't see the new selection of connections in the component editor. Also, for a 3-pole normally open contact, it still only shows 1 and 3, and yes, the program is now crashing more often for me in the component editor.

Hello Thomas, can’t you see the new option in the editor for terminals?

As for the crashes in the element editor, I’ve noticed that I can cause the programme to crash by quickly changing the size of a static text input field using the mouse wheel. I can reproduce this even on older versions such as 0.7, 0.8, 0.9... I’ve checked on my Windows 10 virtual machine running the latest MSI installer, but I can’t reproduce this crash.

In older projects, the `terminal_name` tag does not exist; consequently, terminal numbers will not be displayed.
@Achim: you could share an little sample?
What you using list mode or cross for XREFs?
I use only list mode, I hate cross.

But I’ve discovered a reproducible crash:

However, a reproducible crash occurs in the element editor when editing static text size spinbox; clicking rapidly on the size selection spin box whilst hovering over it with the mouse wheel to quickly scroll through the drop-down list in order to rapidly decrease or increase the value causes the application to crash.

This bug was very old I can crash old: 0.9, 08, 07 appImages...

4618.563460] qelectrotech[180110]: segfault at 0 ip 00007f43d435cac0 sp 00007ffd6d6b9380 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f43d4310000+a8000] likely on CPU 9 (core 12, socket 0)
[54618.563475] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[55407.159955] qelectrotech[289531]: segfault at 0 ip 00007f1ff6b5cac0 sp 00007ffe3bc56f70 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f1ff6b10000+a8000] likely on CPU 15 (core 20, socket 0)
[55407.159971] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[55878.824942] qelectrotech[294763]: segfault at 0 ip 00007fdf7c317ac0 sp 00007fff4c4833c0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7fdf7c2cb000+a8000] likely on CPU 40 (core 21, socket 0)
[55878.824959] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[55926.713745] qelectrotech[295041]: segfault at 0 ip 00007f36b9f5cac0 sp 00007ffe2f9c84e0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f36b9f10000+a8000] likely on CPU 17 (core 22, socket 0)
[55926.713760] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[56039.003506] qelectrotech[295419]: segfault at 0 ip 00007f391635cac0 sp 00007ffde0a72510 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f3916310000+a8000] likely on CPU 15 (core 20, socket 0)
[56039.003522] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[62132.993660] qelectrotech[370775]: segfault at 0 ip 00007f473455cac0 sp 00007ffe223d3de0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f4734510000+a8000] likely on CPU 16 (core 21, socket 0)
[62132.993676] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[62177.491767] qelectrotech[370978]: segfault at 0 ip 00007f45f55e0ac0 sp 00007ffe5fcedef0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f45f5594000+a8000] likely on CPU 15 (core 20, socket 0)
[62177.491782] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[63808.277931] qelectrotech[374595]: segfault at 0 ip 00007f1538f5cac0 sp 00007ffd50716220 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f1538f10000+a8000] likely on CPU 15 (core 20, socket 0)
[63808.277947] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[64010.287344] qelectrotech[376296]: segfault at 0 ip 00007f6862b5cac0 sp 00007ffe2af56ef0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f6862b10000+a8000] likely on CPU 15 (core 20, socket 0)
[64010.287360] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[64259.990010] qelectrotech[378588]: segfault at 0 ip 00007f863915cac0 sp 00007ffc45c147c0 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f8639110000+a8000] likely on CPU 16 (core 21, socket 0)
[64259.990028] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[66222.289237] qelectrotech[381720]: segfault at 0 ip 00007f21cd55cac0 sp 00007ffed7756630 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7f21cd510000+a8000] likely on CPU 15 (core 20, socket 0)
[66222.289251] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[67221.833917] qelectrotech[384539]: segfault at 0 ip 00007fcb6e9edac0 sp 00007ffee8437890 error 4 in libQt5WaylandClient.so.5.15.17[b1ac0,7fcb6e9a1000+a8000] likely on CPU 15 (core 20, socket 0)
[67221.833932] Code: 4c 89 d6 4c 8d 2c 85 00 00 00 00 4a 8d 7c 15 00 48 29 ee 0f 1f 80 00 00 00 00 4c 89 c9 31 d2 66 66 2e 0f 1f 84 00 00 00 00 00 <0f> b6 44 16 01 45 0f b6 64 12 01 48 83 c1 04 41 c1 e4 08 c1 e0 10
[67436.543199] qelectrotech[385262]: segfault at 0 ip 00007ff13359e7b0 sp 00007ffcad687ff0 error 4 in libQt5XcbQpa.so.5[b67b0,7ff133518000+8e000] likely on CPU 15 (core 20, socket 0)
[67436.543214] Code: 8b 54 24 28 4c 29 f6 4c 01 f7 48 8d 1c 95 00 00 00 00 0f 1f 84 00 00 00 00 00 4e 8d 04 36 4c 89 d1 31 d2 85 ed 74 36 0f 1f 00 <0f> b6 44 16 01 45 0f b6 7c 10 01 48 83 c1 04 41 c1 e7 08 c1 e0 10
[67484.866151] qelectrotech[385406]: segfault at 0 ip 00007fe18ff9e7b0 sp 00007ffe0092fa20 error 4 in libQt5XcbQpa.so.5[b67b0,7fe18ff18000+8e000] likely on CPU 39 (core 20, socket 0)
[67484.866166] Code: 8b 54 24 28 4c 29 f6 4c 01 f7 48 8d 1c 95 00 00 00 00 0f 1f 84 00 00 00 00 00 4e 8d 04 36 4c 89 d1 31 d2 85 ed 74 36 0f 1f 00 <0f> b6 44 16 01 45 0f b6 7c 10 01 48 83 c1 04 41 c1 e7 08 c1 e0 10
[67556.962754] qelectrotech[385588]: segfault at 0 ip 00007f8fb2603380 sp 00007ffc187a3c50 error 4 in libQt5XcbQpa.so.5[e2380,7f8fb2559000+dc000] likely on CPU 15 (core 20, socket 0)
[67556.962768] Code: 48 89 fe 45 0f b7 f2 48 89 c3 49 c1 e6 02 4c 29 e6 4c 01 e7 66 0f 1f 44 00 00 4e 8d 0c 26 48 89 d9 31 d2 45 85 c0 74 35 66 90 <0f> b6 44 16 01 45 0f b6 6c 11 01 48 83 c1 04 41 c1 e5 08 c1 e0 10
[67656.520957] qelectrotech[385802]: segfault at 0 ip 00007f441494d380 sp 00007ffefee6f8d0 error 4 in libQt5XcbQpa.so.5[e2380,7f44148a3000+dc000] likely on CPU 6 (core 8, socket 0)
[67656.520973] Code: 48 89 fe 45 0f b7 f2 48 89 c3 49 c1 e6 02 4c 29 e6 4c 01 e7 66 0f 1f 44 00 00 4e 8d 0c 26 48 89 d9 31 d2 45 85 c0 74 35 66 90 <0f> b6 44 16 01 45 0f b6 6c 11 01 48 83 c1 04 41 c1 e5 08 c1 e0 10
[68184.980531] qelectrotech[386496]: segfault at 0 ip 00007f8e598bc398 sp 00007ffda42c0dc0 error 4 in libQt5XcbQpa.so.5[bc398,7f8e59800000+14e000] likely on CPU 15 (core 20, socket 0)
[68184.980545] Code: 95 00 00 00 00 48 89 cd 66 2e 0f 1f 84 00 00 00 00 00 49 89 fa 31 c9 4c 89 de 4d 29 f2 45 85 c0 4e 8d 0c 37 74 36 0f 1f 40 00 <41> 0f b6 44 0a 01 48 83 c6 04 c1 e0 10 89 c2 41 0f b6 44 09 01 0d
[68255.801243] qelectrotech[386764]: segfault at 0 ip 00007ff1778cec68 sp 00007fff20112550 error 4 in libQt5XcbQpa.so.5[cec68,7ff177800000+194000] likely on CPU 15 (core 20, socket 0)
[68255.801258] Code: 4d 63 ed 48 c1 e0 02 49 89 c7 0f 1f 84 00 00 00 00 00 49 89 fb 31 c9 4c 89 e6 4d 29 eb 45 85 c0 4e 8d 0c 2f 74 36 0f 1f 40 00 <41> 0f b6 44 0b 01 48 83 c6 04 c1 e0 10 89 c2 41 0f b6 44 09 01 0d

Edit : libQt5WaylandClient.so.5.15.17, libQt5XcbQpa.so.5 so only reproductible on Debian Sid?

Hi all,

Following the previous commit that displays terminal names on contact symbols in Xref (both Contact and Cross modes), I've been working on extending the feature to power contacts and switch (SW) contacts.

Here is what has been implemented:

**Power contacts (e.g. 3-pole contactor, 6 terminals)**

Cross mode: all terminals are collected and sorted numerically → [1-2-3-4-5-6] P1-H9
Contacts mode: each pole displays its own pair:
- Pole 1 → 1 (left) / 2 (right)
- Pole 2 → 3 (left) / 4 (right)
- Pole 3 → 5 (left) / 6 (right)

**SW contacts with typed terminals**

To solve the ambiguity of SW contacts (which appear in both NO and NC columns), TerminalData::Type has been extended with three new semantic values:

enum Type { Generic, Inner, Outer, No, Nc, Common };

Users can now assign a role to each terminal of a SW element directly in the element editor (new entries in the Type combobox: "NO (contact SW)", "NC (contact SW)", "Commun (contact SW)").

Once typed, the Xref displays the correct pair per column:
- NO column: NO + Common pair, e.g. [14-13]
- NC column: NC + Common pair, e.g. [12-13]
- Contacts mode: NO top-left, NC bottom-left, Common right

Elements without explicit terminal types fall back to the previous behavior (first 2 named terminals) — fully backward compatible.

This change affects:
- terminaldata.h / terminaldata.cpp — new enum values + serialization
- terminal.h / terminal.cpp — new public terminalType() accessor
- terminaleditor.cpp — new entries in the type combobox + pre-existing bug fix in updateForm()
- crossrefitem.cpp — filtering by type in Cross and Contacts modes

Joshua, Achim, plc-user, Kellermorph — what do you think?

EDIT: Pushed to the master branch and compiled the main packages.

2026-05-22 22:50:32

Kellermorph wrote:

i think yes.
because in this Picture Bildschirmfoto_20260522_202722.png you can see, that the Contactsnumbers that are visible are completly wrong.

Hum, ok!
For now we search only terminals: [0] [1] [2] so it's wrong for power element with 6 terminals like this capture.

So

scorpio810 wrote:

The proper solution is to use TerminalData::Type and add the missing values:

Thus, in the .elmt file, each terminal has its explicit role, independent of the order. And in crossrefitem.cpp we filter:
enum Type {
Generic,
Inner,
Outer,
No, // ← new
Nc, // ← new
Common // ← new
};
NO side → terminals of type No + Common
NC side → terminals of type Nc + Common
This change affects:
terminaldata.h — add the values to the enum
terminaldata.cpp — typeToString / typeFromString
The element editor — UI for selecting the type
crossrefitem.cpp — filter by type

What do you think about this change?

2026-05-22 22:11:08

@Kellermorph: For the time being, I don’t plan to include the terminal numbers for the power contacts – is that useful, I think no?

2026-05-22 21:16:25

kellermorph wrote:

For a changeover contact, contact 11 isn’t displayed as a terminal contact, and for a 3-pole normally open contact, only 2 terminal numbers are shown, and these keep repeating. The other 4 are left out.

What do you think when you wrote to :The other 4 are left out?
You ask for like an 4 changeover contact?

Like 4 positions switch, mercury switch 4 terminals?

2026-05-22 21:01:01

Can you test this patch?
last captures is based on!; or I push it?
https://qelectrotech.org/forum/misc.php … download=1

2026-05-22 14:23:18

Hi all,

Following the recent commit that displays terminal names on contact symbols in Xref Contact mode, I've been working on extending the same feature to Cross mode.

The implementation is straightforward: for each slave element in the NO and NC columns, we prepend the terminal names as "[13-14] 1-C3" inline with the position text. The cross width is recalculated accordingly.

However, we ran into a fundamental limitation with switch contacts (SW):

A SW element appears in both the NO and NC columns. With the current approach of simply taking the first 2 named terminals, both sides display the same label (e.g. [12-13]), which is incorrect — the NO side should show the NO+common pair and the NC side the NC+common pair.

The core problem is that the order of terminals in the XML depends entirely on how the user built the element in the editor. There is no guaranteed convention like [0]=NO, [1]=common, [2]=NC.

Two possible approaches to discuss:

1. Simple convention (user responsibility)
Keep the current implementation (first 2 named terminals) and document that users must name and order their terminals correctly in the element editor. This is consistent with what I'm stated: "Users are expected to name their own terminals in the element editor." Simple, no breaking changes, works perfectly for NO/NC classics (13-14, 23-24, 11-12, 21-22...).

2. Extend TerminalData::Type enum
Add semantic types to TerminalData:

enum Type { Generic, Inner, Outer, No, Nc, Common };

This would allow crossrefitem to filter terminals by role regardless of their order in the XML:
- NO column: show terminals typed No + Common
- NC column: show terminals typed Nc + Common

This requires changes to terminaldata.h, terminaldata.cpp (typeToString/typeFromString), the element editor UI, and crossrefitem.cpp. More work, but the only truly robust solution for SW contacts.

Thoughts? Is option 2 worth pursuing, or is option 1 acceptable given that SW contacts with named terminals are an edge case?

The current patch (option 1) is working well for standard NO/NC contacts and is ready to submit if the all in the team agrees with the approach.

The proper solution is to use TerminalData::Type and add the missing values:

Thus, in the .elmt file, each terminal has its explicit role, independent of the order. And in crossrefitem.cpp we filter:

enum Type {
    Generic,
    Inner,
    Outer,
    No,      // ← new
    Nc,      // ← new
    Common   // ← new
};

NO side → terminals of type No + Common
NC side → terminals of type Nc + Common

This change affects:
terminaldata.h — add the values to the enum
terminaldata.cpp — typeToString / typeFromString
The element editor — UI for selecting the type
crossrefitem.cpp — filter by type

Joshua, Achim, plc-user, kellermorph,what do you think about?

Latest patch for cross.

2026-05-22 11:46:43

https://github.com/qelectrotech/qelectr … r/pull/464

Kellermorph wrote:

New element for wire definition.
Advantages: It doesn't create an open end like a sheet reference, and I can filter it out of the wiring diagram in the subsequent pull request to prevent incorrect connections from being displayed, unlike with the sheet reference.

2026-05-21 17:46:11

scorpio810 wrote:

scorpio810 wrote:
crossrefitem: display terminal names on contact symbols in Xref
When a slave element has named terminals in its element definition
(.elmt), the terminal names (e.g. 13/14 for NO, 11/12 for NC,
12/13/14 for SW) are now displayed on each side of the contact
symbol in the cross-reference view.
- NO/NC contacts: name[0] on the left, name[1] on the right
- SW contacts: name[0] (NO) top-left, name[1] (common) top-right,
name[2] (NC) bottom-left
Terminal names are read from Terminal::name() which is populated
from TerminalData::m_name during element parsing. If terminals are
not named, nothing is displayed (fully backward compatible).
Users are expected to name their own terminals in the element
editor to avoid duplicating elements in the official collection.

2026-05-21 17:15:35

https://github.com/qelectrotech/qelectr … 86b0ce2636

scorpio810 wrote:

crossrefitem: display terminal names on contact symbols in Xref
When a slave element has named terminals in its element definition
(.elmt), the terminal names (e.g. 13/14 for NO, 11/12 for NC,
12/13/14 for SW) are now displayed on each side of the contact
symbol in the cross-reference view.
- NO/NC contacts: name[0] on the left, name[1] on the right
- SW contacts: name[0] (NO) top-left, name[1] (common) top-right,
name[2] (NC) bottom-left
Terminal names are read from Terminal::name() which is populated
from TerminalData::m_name during element parsing. If terminals are
not named, nothing is displayed (fully backward compatible).
Users are expected to name their own terminals in the element
editor to avoid duplicating elements in the official collection.

Ps: it's work on list mode not in cross XREFs
BTW for checting I enter hazardus terminal name in this capture: joke!

Enjoy! nomicons/wink

Another step is to control you can't linked an antother slave contact if terminal_name was already into the list.
I don’t think it’s necessary to include the names of power contacts on this list, like contactors..

2026-05-21 14:49:02

✅ SignPath integration — MSI signed automatically
✅ Unique ProductCode per build based on the Git SHA
✅ FIX MajorUpgrade triggers correctly — a single entry in Settings remove programs

Roadmap :

Await the EV certificate from the SignPath Foundation
Change test-signing to release-signing in windows-msi.yml
Add the SignPath signature to windows-build.yml for the NSIS .exe and Ready-To-Use
Configure the NSIS project in SignPath

2026-05-21 06:07:12

Hi,
this rules was wrtited on XML of your project file .qet, just copy these rules lines on your new project with a good text editor.

2026-05-21 04:11:43

✅ Removed the QET.bat launcher from the MSI
✅ Desktop and Start menu shortcuts now point directly to qelectrotech.exe
✅ CustomAction that sets the ‘elements’ folder to read-only after installation
✅ No more black console window on launch

2026-05-20 17:15:50

axel.genet wrote:

Bonjour, oui je vous confirme que c'était monstrueux à faire, c'est pour cela qu'on recherche à faire la même chose sur QET

Clair, il manque le plus important en dépannage!: Les renvois de folio, les références croisées maitre esclaves, etc.
Excel n'est pas adapté pour ce travail même si ça peut faire le job faute de logiciel elec qui coûtent une fortune, c'est un tableur....à la base.

Search options (Page 1 of 305)

Posts found: 1 to 25 of 7,601

1 Reply by scorpio810 Yesterday 17:37:10

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

2 Reply by scorpio810 Yesterday 15:52:08

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

3 Reply by scorpio810 Yesterday 15:37:24

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

4 Reply by scorpio810 Yesterday 14:31:48

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

5 Reply by scorpio810 Yesterday 13:58:54

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

6 Reply by scorpio810 Yesterday 13:40:45

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

7 Reply by scorpio810 Yesterday 13:35:31

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

8 Reply by scorpio810 Yesterday 13:24:40

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

9 Reply by scorpio810 Yesterday 13:09:45

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

10 Reply by scorpio810 Yesterday 12:49:38

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

11 Reply by scorpio810 Yesterday 12:34:11

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

12 Reply by scorpio810 Yesterday 02:43:49

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

13 Reply by scorpio810 Yesterday 01:48:25

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

14 Reply by scorpio810 2026-05-22 22:50:32

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

15 Reply by scorpio810 2026-05-22 22:11:08

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

16 Reply by scorpio810 2026-05-22 21:16:25

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

17 Reply by scorpio810 2026-05-22 21:01:01

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

18 Reply by scorpio810 2026-05-22 14:23:18

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

19 Reply by scorpio810 2026-05-22 11:46:43

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

20 Reply by scorpio810 2026-05-21 17:46:11

Re: Problème de N° manquant sur référence croisée (33 replies, posted in FR : Aide, suggestions, discussions, ...)

21 Reply by scorpio810 2026-05-21 17:15:35

Re: Nouveautés de la version de développement 0.9 and 0.100.0 -0.100.1 (269 replies, posted in News)

22 Reply by scorpio810 2026-05-21 14:49:02

Re: Installation (11 replies, posted in Platform-specific problems: Windows,)

23 Reply by scorpio810 2026-05-21 06:07:12

Re: numbering rules of the current project to a new project? (1 replies, posted in EN : Help, suggestions, discussions, ...)

24 Reply by scorpio810 2026-05-21 04:11:43

Re: Installation (11 replies, posted in Platform-specific problems: Windows,)

25 Reply by scorpio810 2026-05-20 17:15:50

Re: Valeurs dynamiques QET (18 replies, posted in FR : Aide, suggestions, discussions, ...)

Posts found: 1 to 25 of 7,601