New .dxf to .elmt Conversion Program (Page 5 of 6)

Hello Vadoola!
Hallo plc-user!

Now the program return a messageBox to inform users if dxf2elmt can't convert DXF files, but I loose QInfo() information about the errors in logs files... which is a bit of a shame, unless you do run dxf2elmt in a CLI terminal to read the convertion error!
if someone can help?

--- sources/dxf/dxftoelmt.cpp
+++ sources/dxf/dxftoelmt.cpp
@@ -22,7 +22,6 @@
 #include <QProcess>
 #include <QMessageBox>
 #include <QDir>
-#include <iostream>
 #include <QDebug>
 
 /**
@@ -45,11 +44,20 @@ QByteArray dxfToElmt(const QString &file_path)
     const QStringList arguments{file_path, QStringLiteral("-v")};
 
     process_.start(program, arguments);
+    // qInfo()<<"\n Start converting DXF file..........\n"<< file_path;
+    // qInfo()<< process_.readAllStandardError(); //Print standard error to log file
 
     if (process_.waitForFinished())
     {
-        qInfo()<<"\n Start converting DXF file..........\n"<< file_path;
-        qInfo()<< process_.readAllStandardError().data(); //Print standard error to log file
+        bool dxf2elmterr = process_.readAllStandardError().isEmpty();
+        QString message=QObject::tr(
+        "Error: Make sure the file is a valid .dxf file");
+        
+        if (!dxf2elmterr){
+        QMessageBox::warning(nullptr,
+                     QObject::tr("Error: to convert this dxf file."),
+                     message);
+        }
 
             const auto byte_array{process_.readAll()};
             process_.close();

Salut Laurent !
Hello Vadoola!

I also played with the possibilities to give more information to the user and learned, that a MessageBox can have three texts:

QMessageBox msgBox;
msgBox.setText("QET_ElementScaler: \nadditional information about import / scaling");
msgBox.setInformativeText("See details here:");
msgBox.setDetailedText(error_output);
msgBox.exec();

That results in this MessageBox (details are hidden by default):

Such an additional MessageBox should only popup, when there really is information for the user: When everything's fine there should be no additional Box to close...

This means that we should be very frugal with any outputs in our CLI software!
If there is nothing to report, then shut up!   

Hello Laurent, plc-user,

@plc-user that multi-info messagebox looks like a useful way to do it. I agree the box should only popup when it's needed to provide info to a user, if everything goes well they should just get the element in the editor.

In verbose mode to print the element to stdout there shouldn't be a lot of information I think if everything goes well it's mostly just created <file_name>.elmt or something like that I would need to go double check. Clearly though something slipped through in my commit. The "Remove Polygon with one less points" was something I had in there when I was testing the most recent couple of commits, which doesn't convert single point polylines, and converts dual point polylines from Polygons to Line Elements. I thought I had removed them all from the code before commiting, but clearly missed something.

Hello Vadoola,

about the definition-line.

The definition-line describes the dimensions of the element and is calculated by the element editor. It is therefore not noticeable that the values have not been calculated (correctly) if the import is carried out directly in the element editor.
If the element is converted on the command line and the element is used directly in the diagram editor, it is not displayed correctly because the width, height and hotspots are not set correctly.
This is particularly noticeable when dragging the element onto the folio, see appendix.

You already write it in a comment in your code (src/qelmt/mod.rs from line 59:

//The original code had the height, and width hard coded to 10
//and the hotspots hard coded to 5. I'm not sure why this is?
//Maybe actually calculating the size wasn't worth it? I'm not sure
//if that info is part of the dxf. And maybe when you open he elemnt
//in the elemtent editor it corrects it anyway. Just look into it, and
//se if this is something that needs to get adjusted.

The values for the definition line can only be calculated correctly if all information about all graphical elements is available.
In QET_ElementScaler I keep the whole QET-element in memory and recalculate the definition-line after scaling and before writing anything to stdout.
The calculation is specific to QET and it took me some time and help from Laurent and Joshua to implement it accordingly.

If you read in the file sequentially and output everything immediately to stdout, the definition-line values can not be correct. As far as I know, the necessary information is not in the dxf...

Hello Vadoola,

start reading here:
https://github.com/plc-user/QET_Element … ts.cpp#L50
it's (almost?) the same as in QET

As input-parameter I use a rectangle that represents the min- and max-values of all graphical elements. This rectangle is a global variable "ElmtMinMax" and is determined during the processing of every part.

Hello Laurent and plc-user,

I'll add it to the list. It looks like the dxf has a text height property, I'm assuming it would be in the same units are the rest of the dxf, ie it's a height in mm, or inches, etc. I would have to convert that into a font size. It looks like I already need to figure out how to do some font processing. One of the forums posts mentioned text not being in the correct spot. I figure out why and documented it in the Issue https://github.com/Vadoola/dxf2elmt/issues/7. Essentially if the horizontal and vertical alignment on the text are not the default (top left), then you need to calculate the location based on a different set of coordinates, and the font rendering. As part of trying to add that in, I can also try to figure out converting the text size in the dxf into a proper font size.

As of right now, dxf2elmt is using the latest official tagged version of dxf-rs from crates.io, which is 0.5.0, tagged all the way back in September 2021.

I have been considering on updating to use the master branch from git, even though it looks like development on dxf-rs has slowed to a crawl there are still updates to the master branch that have happened int he last 3 years.

I think I've seen at least 2 or 3 of these where the dxf reading fails due to some unsupported code point. The past couple of weeks since I tagged 0.4.0 has been mostly investigating issues, and brainstorming. I may try and update dxf-rs to the master branch and see if that breaks anything, and if it fixes any of these reported issues as well.

It looks like the function was renamed at some point from get_is_closed to just is_closed, the source between the 2 is identica.

0.5.0

pub fn get_is_closed(&self) -> bool {
        self.flags & 1 != 0
    }

Master

pub fn is_closed(&self) -> bool {
        self.flags & 1 != 0
    }

I haven't tested it properly, but just replacing all the .get_is_closed() function calls with .is_closed() makes it compile for me

Windows 64 binary.

I've noticed that many more DXF files are now being converted,
whereas previously they would generate an error and can't be converted....