101

(38 replies, posted in Code)

Beide Varianten können nicht funktionieren, weil:

/home/ich/Projekte/c_c++/QET/sources/print/projectprintwindow.cpp:720: Fehler: ‘class DiagramTextItem’ has no member named ‘isCrossReference’
../../sources/print/projectprintwindow.cpp: In member function ‘void ProjectPrintWindow::addPdfLinks(QPainter*, Diagram*)’:
../../sources/print/projectprintwindow.cpp:720:39: error: ‘class DiagramTextItem’ has no member named ‘isCrossReference’
  720 |                         if (textItem->isCrossReference()) {
      |                                       ^~~~~~~~~~~~~~~~


Vielleicht solltest Du doch mal versuchen, selber zu kompilieren:
Es macht nur begrenzt Spaß, für andere einen Code zu compilieren, der von einer "Intelligenz" entworfen wurde, die die Rahmenbedingungen von QET nicht zu kennen scheint!

102

(38 replies, posted in Code)

Die Funktion wird deshalb nicht aufgerufen, weil sie in der if (fit_page) nur im else-Zweig aufgerufen wird, aber die if-Bedingung (fit_page) erfüllt ist!

103

(38 replies, posted in Code)

Habe auch mal die Funktion "void ProjectPrintWindow::addPdfLinks" geleert und nur eine qInfo()-Ausgabe eingefügt.

Die Funktion wird nicht aufgerufen!
Nicht beim Ausdruck in PDF und auch nicht beim PDF-Export.

104

(38 replies, posted in Code)

Laß uns zu Deutsch wechseln ... liegt uns beiden wahrscheinlich besser!  nomicons/wink

Die Warnungen habe ich behoben.
Der Fehler ist immer noch drin!

105

(38 replies, posted in Code)

Tried the code with Debian GNU/Linux stable and Qt 5.15.8

There was a Warning about deprecated calls (fixed that) and an Errror:

(...)/QET/sources/print/projectprintwindow.cpp:798: Fehler: cannot ‘dynamic_cast’ ‘item’ (of type ‘class QGraphicsItem*’) to type ‘class DiagramTextItem*’ (target is not pointer or reference to complete type)
../../sources/print/projectprintwindow.cpp: In member function ‘void ProjectPrintWindow::addPdfLinks(QPainter*, Diagram*)’:
../../sources/print/projectprintwindow.cpp:798:29: error: cannot ‘dynamic_cast’ ‘item’ (of type ‘class QGraphicsItem*’) to type ‘class DiagramTextItem*’ (target is not pointer or reference to complete type)
  798 |         if (auto textItem = dynamic_cast<DiagramTextItem *>(item)) {
      |                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

removed the double #include "projectprintwindow.h", too.

Hallo Achim,

auch weil wir gerade heute das Thema *-Verzeichnis hatten...
Insgesamt haben wir ähnliche Lösungsansätze.

Deine Variante hat nur einem "Haken": Jeder einzelne "Kontakt" taucht separat in der BOM auf. Siehe Anhang!

Eine Kombination aus beiden wäre es wahrscheinlich!

@tigerbeard:
Gib' doch mal Bescheid, für welche Lösung Du Dich entschieden hast!
Vielleicht ist Dir ja noch was viel Schlaueres eingefallen!

Moin!

Das Inhaltsverzeichnis und auch das für die Betriebsmittel werden dynamisch durch SQL-Abfragen der Projekt-internen Datenbank erzeugt. Daher wirst Du nicht umhin kommen, dich damit zu beschäftigen.
Die interne DB ist eine SQLite-Datenbank und auf deren Seite gibt es auch Informationen zur formatierten Ausgabe mit "printf":
https://www.sqlite.org/printf.html
Dazu gab es auch schon vereinzelt Posts in diesem Forum, aber eine gute Zusammenfassung oder gar Anleitung steht noch aus, fürchte ich...
Im Anhang habe ich mal ein Beispiel angefügt, mit dieser SQL-Abfrage:

SELECT printf("%10s", folio) Folio, printf("%-170s", title) Beschreibung, indexrev, printf("%-50s", author) Bearbeiter, date FROM project_summary_view

Vielleicht hilft Dir das schon weiter für die Erstellung eines schönen Inhaltsverzeichnis und einer noch besseren Anleitung? nomicons/wink

Hier die zugehörige qet-Datei, aus der Du die Elemente in deine Benutzersammung ziehen kannst.

Bei der Gestaltung der Master- bzw. Slave-Elemente bist du ziemlich frei!

Habe mal fix einen Master und einen Slave erstellt, die Deiner Vorstellung schon ziemlich nahe kommen könnten:
Am Master definiert man das Betriebsmittelkennzeichen, das von den Slaves übernommen wird.
Damit die Zeichnug dann nicht mit -zig "-X27" überfrachtet wird, weil bei es an jedem Slave steht:
Kein Dynamisches Textfeld mit dem BMK in die Slave-Elemente einfügen! Siehe Beispiel.

Ansonsten bist Du wirklich sehr frei in der Gestaltung!
Ein Rechteck kannst Du dann im Schaltplaneditor separat drüber ziehen...

... but I'm repeating myself:
https://qelectrotech.org/forum/viewtopi … 443#p19443

Echte dynamische Elemente suchst Du hier leider (noch) vergebens!

Alternativ kämen vielleicht Master-Slave-Lösungen in Frage?
Du kannst jedenfalls eine (unbegrenzte?) Zahl an Slave-Elementen an einen Master hängen.
Das wäre auch mein Vorschlag für sehr umfangreiche Geräte:
Bevor ich ein sehr komplexes Element mit mehreren -zig I/O erstelle, mache ich lieber ein Master-Element (z.B. den Teil mit der Einspeisung oder der CPU) und hänge daran die Funktionsgruppen als Slave-Elemente an.


PS:
Ein aussagekräftiger Betreff passend zum Thema wäre besser:
Begeisterte Nutzer haben wir hier viele!  nomicons/wink

It is not QElectroTech that is the problem, but the fonts you have installed on your systems and which you used for the texts!
QElectroTech only shows, that the font you chose on one system to use for texts is not available on the system, you opened the QET-Project later!

Example:
"Sans Serif" or "ms_shell_dlg" are just placeholders for the real font the system uses. If you want, you can set a Greek font as replacement for them in system-settings.

When you want, that texts look alike on all systems you use:
Install and use the same font (*.ttf) everywhere!

Deleted double-post in English Forum!

114

(117 replies, posted in Code)

I use the versions coming with Debian GNU/Linux unstable to compile for Qt6: 6.8.2

I see that your knowledge of Qt goes much further than mine! That's why I have no problem with you staying on the subject of “SingleApplication”: You've already read up on it in docs and sources...

As I learned to know you so far, I guess you'll find a solution for the crash, too!  nomicons/smile

115

(117 replies, posted in Code)

Hello everybody!

Did someone notice this:
While trying elevatorsmind's "Autosave" I killed the execution of QET and it cannot be started again!

This only is the case with the Qt6-Build and has nothing to do with "Autosave"!
It seems that singleapplication prevents a new re-start, because something is left behind, when killed!

I already try to find a solution (and it seems, I have found!), but before I waste too much time: Did someone notice this effect, too?

116

(117 replies, posted in Code)

@elevatormind:

I haven't paid much attention to the stalefiles so far, but now that “we” want to organize them completely ourselves as “ Autosave”, I tried out your source code directly and am quite impressed!  nomicons/smile

Only two comments on the source code:

  • All other directory names are written in lower case.

  • If “QETApp::dataDir()” were also used here as the base directory, we would still have only one place in the source code where these base directories (dataDir, configDir, pictureDir...) are managed. The line lengths would also be much shorter nomicons/wink

(...)
#include "qetapp.h"
(...)
setFileTemplate(QETApp::dataDir() + "/autosave/qet_autosave_XXXXXX");
(...)
auto asf_dir = QDir(QETApp::dataDir() + "/autosave");
(...)

117

(23 replies, posted in Code)

@Re-searcher:
You still did not explain, what you think does "not work" with bigger grid-points.
You need to explain, what you expect to see with bigger points!

118

(23 replies, posted in Code)

@Re-searcher:

I do not know, what you are complaining about:
The settings does exactly, what it is made for: "Set the grid-dot-size to the value in the spinbox"
It looks like you chose a setting of "5" for the screenshots you made.
When I look at your screenshots, all grid-dots in both screenshots have the same height and width of 5x5.

And as written before:
The size of the grid-points does not change with zoom-factor in QET!

In relation the points look smaller, when zooming in a design.
But that's just an optical illusion:
Use a graphic-software to check the size in both screenshots!
You will see, that all points have the same size of "5x5" in your screenshots.

In the attachment you see both of your screenshots zoomed to 1200% with GIMP (no shouting here: it spells with capital letters).
I marked the diagonal of your black dots with red pixels, so you can count: 5 in each of your screenshots.

119

(117 replies, posted in Code)

Hallo Achim,

achim wrote:

Wenn man ein schon plaziertes Terminal-Element mit der Leertaste
rotiertieren will, springt das Terminal auf den Ursprong (0,0) zurück.
Ist sicher nicht so gewollt.

Richtig: Das ist nicht so gewollt und es betrifft nicht nur Terminals.
Das ist mir auch schon aufgefallen und bedarf noch etwas Hirnschmalz.
Habe das Verhalten für den Moment aber billigend in Kauf genommen, weil das Ergebnis (Rotieren, Spiegeln, Umdrehen) deutlich besser ist, als was wir vorher hatten.

Zwischendurch das Element speichern und neu laden, hilft aber!


Addendum:
I'm working on a solution ... looks better at first glance!

2nd addendum (edited):
Fix released with version ...git8427...

120

(117 replies, posted in Code)

Hallo Achim,

Danke für Deine Rückmeldung!

Es geht primär darum, daß das mal jemand anderes ausprobiert, ob alles noch so geht, wie vorher:
Aus einem Schaltplan ein Element löschen, das mehrere Verbindungen an einem Anschlußpunkt hat, wiederherstellen, etc.

Manchmal sieht man den Wald vor lauter Bäumen nicht und wird "Betriebsblind" und sieht die eigenen Fehler nicht,

Dann werde ich das mal als PR einreichen.

121

(117 replies, posted in Code)

Hello everybody!

I would like to get rid of those many Qt5/Qt6 - differentiations in sourcecode, so I tried something that seems to work for both, but to be sure:
Can someone please test this patch with undocommand/deletegraphicsitemcommand

diff --git a/sources/undocommand/deleteqgraphicsitemcommand.cpp b/sources/undocommand/deleteqgraphicsitemcommand.cpp
index 5aa85ca42..632c64a9a 100644
--- a/sources/undocommand/deleteqgraphicsitemcommand.cpp
+++ b/sources/undocommand/deleteqgraphicsitemcommand.cpp
@@ -179,7 +179,7 @@ void DeleteQGraphicsItemCommand::setPotentialsOfRemovedElements()
                     //If a conductor was already created between these two terminals
                     //in this undo command, from another removed element, we do nothing
                 bool exist_ = false;
-                for (QPair<Terminal *, Terminal *> pair : m_connected_terminals)
+                for (std::pair<Terminal *, Terminal *> pair : m_connected_terminals)
                 {
                     if  (pair.first == hub_terminal && pair.second == t) {
                         exist_ = true;
@@ -192,14 +192,8 @@ void DeleteQGraphicsItemCommand::setPotentialsOfRemovedElements()
 
                 if (exist_ == false)
                 {
-#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)    // ### Qt 6: remove
-                    m_connected_terminals.append(qMakePair<Terminal *, Terminal *>(hub_terminal, t));
-#else
-#if TODO_LIST
-#pragma message("@TODO remove code for QT 6 or later")
-#endif
-                    qDebug()<<"Help code for QT 6 or later";
-#endif
+                    m_connected_terminals.append(std::make_pair<Terminal *, Terminal *>((Terminal *)hub_terminal, (Terminal *)t));
+                    qInfo() << "m_connected_terminals" << m_connected_terminals;
                     Conductor *new_cond = new Conductor(hub_terminal, t);
                     new_cond->setProperties(properties);
                     new AddGraphicsObjectCommand(new_cond, t->diagram(), QPointF(), this);
diff --git a/sources/undocommand/deleteqgraphicsitemcommand.h b/sources/undocommand/deleteqgraphicsitemcommand.h
index 2f03ed050..c4ad2946b 100644
--- a/sources/undocommand/deleteqgraphicsitemcommand.h
+++ b/sources/undocommand/deleteqgraphicsitemcommand.h
@@ -52,7 +52,7 @@ class DeleteQGraphicsItemCommand : public QUndoCommand
         QHash <Element *, QList<Element *> > m_link_hash; /// keep linked element for each removed element linked to other element.
         QHash <DynamicElementTextItem *, Element *> m_elmt_text_hash; /// Keep the parent element of each deleted dynamic element text item
         QHash <DynamicElementTextItem *, ElementTextItemGroup *> m_grp_texts_hash; ///Keep the parent group of each deleted element text item
-        QList <QPair<Terminal *, Terminal *>> m_connected_terminals;
+        QList <std::pair<Terminal *, Terminal *>> m_connected_terminals;
         QHash <QetGraphicsTableItem *, QPointer<QGraphicsScene>> m_table_scene_hash;
         bool m_remove_linked_table = false;
 };

These functions handle the case that an element, that has more than one connections at one terminal, is deleted and then recovered again.
Don't want to demolish basic functions, so to be sure...

Thanks in advance!

In my opinion, it would be a great improvement if we could get rid of these two! It seems that QET is the only project that uses these two libraries and they keep causing problems when using Qt-Creator. When searching the web for these two libraries it always comes back to the same results in this forum...

I will try your solution later and report back

EDIT:
As far as I can see, the code for ColorButton and ColorComboBox works fine and I could eliminate KWidgetsAddons from includes and libs!

I found a better solution for using KF6CoreAddons and KF6WidgetsAddons from distribution-packages!

In my local qelectrotech.pro I added these lines to global part, so that the include-files can be found:

INCLUDEPATH += /usr/include/KF6/KCoreAddons
INCLUDEPATH += /usr/include/KF6/KWidgetsAddons

The linker needs the information, where to find the libs, so I added these lines to the "unix"-section:

LIBS += /usr/lib/x86_64-linux-gnu/libKF6CoreAddons.so
LIBS += /usr/lib/x86_64-linux-gnu/libKF6WidgetsAddons.so

Now everything compiles and links fine without exclamation-marks or red texts in edit-lines in Qt-Creator!

This info might help someone install and use Qt-Creator on Linux to help develop QElectroTech!

124

(23 replies, posted in Code)

An explanation:
The height and width of the grid-points does not grow with zoom-factor in QET!
It is always the number of pixels on your screen for width/height of the grid-points.
Maybe a maximum of "5" isn't enough for High-DPI-Screens. But that could be changed very easily in sources...

125

(23 replies, posted in Code)

... works also in element-editor: