Thanks @JonB . I will read the documentation more carefully. @JonB said in Constraining user input to a QLineEdit: If you want to work from Designer, it will save a .ui file and your build process will run uic on that to generate a ui_....h file containing C++ code implementing what you have designed. And the will be #included into a class_name.cpp file you compile. Ok so there is an additional, pre-compiler compiler other than the moc right? So the uic translates the xml from the .ui files into the ui_.h headers, then the moc runs though all the code in the rest of the source and does it's thing, then that all gets fed to the compiler proper. Or some variant thereof? Cool. Usually it's better not to findChild<>() from the outside world. So not kosher to call this from a descendant of QDialog for example? That is what you mean by outside world? Thx again for the help @JonB et. al. The Qt community is very helpful and friendly! BTW: This worked much better after I thought about what you said earlier: void fltsetter::hdlTextEdited(const QString &text) { int currentCursorPos; qInfo() << "fltsetter::hdlTextEdited(" << text << ")"; qInfo() << "Current cursor pos: " << (currentCursorPos = editor->cursorPosition()); qInfo() << "Last cursor pos: " << lastCursorPos; qInfo() << "size: " << editor->text().size(); disconnect(editor, &QLineEdit::textEdited, this, &fltsetter::hdlTextEdited); // 1. If adding char at position 2, insert decimal if ((currentCursorPos == 2) && (lastCursorPos == 1)) { qInfo() << "Inserting decimal"; editor->insert("."); qInfo() << "New cursor pos: " << (lastCursorPos = editor->cursorPosition()); } // 2. If adding third char after decimal erased, insert a decimal in pos 3 else if ((currentCursorPos == 3) && (lastCursorPos == 2) && (text.back() != ".")) { qInfo() << "Substituting decimal"; auto lastChar = text.back(); editor->backspace(); editor->insert("."); qInfo() << "Last char: " << lastChar; editor->insert(lastChar); qInfo() << "New cursor pos: " << (lastCursorPos = editor->cursorPosition()); } connect(editor, &QLineEdit::textEdited, this, &fltsetter::hdlTextEdited); qInfo() << "New cursor pos: " << (lastCursorPos = editor->cursorPosition()); }

I'm here to get some feedback and gauge interest in this C++ library. A brief rundown: Azuti (ah-ZOO-tee) is a W3C standards-compliant library written in modern C++17/20. It was originally built as the “Model” for a vector drawing application (SaviDraw), where it powered SVG-based document structures in an MVVM architecture. Azuti is a made up namespace identifier that doesn't really mean anything. Standards coverage (as of 2025 living specs) DOM 4 – ~98% implemented. Selectors 3 – basic functions (stubs for namespaces & pseudo-elements). CSSDOM 2 Rules – subset for SVG (extensible for general CSS). CSS Object Model. CSS Syntax Module Level 3. Geometry Level 1 – full coverage. SVG 2 – ~50% (features needed for SaviDraw). HTML – currently a stub, but expandable; elements without a corresponding C++ class are instantiated as generic Element nodes with attributes preserved. Note: I'm in the process of updating the core DOM 4 mutation and event algorithms to support shadow trees. Key design details Written in modern C++ (17/20) Statically-linked: takes advantage of the standard library, no runtime dependencies. No naked pointers: all ownership is expressed through smart pointers. Tested in a production application (SaviDraw). Style resolution fully follows W3C rules (inheritance, scoping, cascading, etc.). Includes a scoping undo manager based on the original W3C spec. Nested transactions are supported—beyond the spec). Uses libxml2's SAX interface to parse text input. Uses the Eigen library for the linear algebra calculations on the SVG end. Potential uses Standards-compliant XML/DOM library. SVG / HTML manipulation and property resolution for the back-end. Basis for application frameworks requiring DOM + CSS models. Provides the document manipulation power of a web browser without all the overhead of a web browser. Business model (early thoughts) Entry tier: binary + header licensing. Upper tiers: potential strategic partnerships for further development. An open-source licensing for commercial use is a possibility. As I mentioned above, Azuti has been real-world tested in an SVG-based vector drawing application. In the M-V-VM architecture, Azuti was the MODEL section. The application interacted with Azuti strictly through the DOM 4 API: mutation observers, events, undo manager, etc. I don't have any links to post yet, it's not vaporware, but I will post the contents of a few header files. I want to know if there would be any interest in commercial licensing of this library?

One possible reason for the blurriness could be that the path data is scaled down too much inside the SvgPathItem. QDS tends to rasterize at lower resolution if the source size and item size don’t match. Keeping the original viewBox from the SVG file and adjusting the width/height proportionally may help.

trying to start test automation from scratch here. I'm working on adding the objects (commonly used basic ones). When I've added an object in the names.py file, when I edit the properties, is there a way to know if the object i still identifiable?

Hey there! You can return to the course in the catalog and relaunch it. Are you experiencing issues with this?

I do a lot of python/pyqt database access using psycopg2 for PostgreSQL. It's so much easier to prototype these kinds of ideas in a language like python, and if needed then port it to c++, but truth be told, most of the time the python app is just works as is so no need to rewrite in c++. For something as simple as you are alluding to, the hard core OO models using DAO/DTO are probably overkill. Also, when dealing qith SQL queries it's "nice" to work in a language that is NOT strongly typed. Sorry if this is a round-about way to respond. Your path has merit in the realm of intellectual curiosity, but if you want it done quickly then python is a better option, and you can still wrap it in a Qt GUI. Yikes! Didn't notice OP was 9 months ago...

Bonjour, Dans votre fonction, call, le device est détruit à la fin de la fonction, Le signal signalWithoutPointer ne peut pas marcher car cela demanderai un copy de l'objet Device mais il s'agit d'un QObject ou le constructeur par copy est désactivé. Le passage d'un pointeur vers Device, ben, la moment juste après le pointeur est null. Le passage avec signal sur pointeur "pointer", lui il marche mais c'est la responsabilité de la classe connection de détruire pointer (et donc de garder une variable dessus). Le plus simple c'est de faire un retour de fonction si vous voulez vous simplifiez la vie. // in Connection.cpp Device* Connection::call() { return new Device("Pointeur"); } //main.qml (à la place de la Connections) property Device device: Connection.call() Dans ce cadre cas là, par passage par pointer via un retour de fonction, l'objet appartiendra au QML et sera détruit par le QML Engine. Cependant, je recommande plutot de passer par une propriété. // in connection.h // je suggère de renommer cette classe en ConnectionController (pour éviter la confusion avec le type qml Connections class Connection : public QObject { Q_OBJECT Q_PROPERTY(Device* device READ device CONSTANT) public: explicit Connection(QObject *parent = nullptr); Device* device() const; private: std::unique_ptr<Device> m_device; }; // in connection.cpp Connection::Connection(QObject *parent) : QObject(parent), m_device(new Device("Pointeur"){} Device* Device::device() const { return m_device.get(); } // main.qml property Device device: Connection.device Ici le device reste la responsabilité de la classe Connection, mais c'est géré par le uinique_ptr. Si le device peut changer, il conviendra d'ajouter un signal deviceChanged et de supprimer le CONSTANT de la Q_PROPERTY pour y mettre un "NOTIFY deviceChanged".

Everything looks right in my eyes. If I e.g. search for @Volker-Hilsheimer's blog post about QRangeModel, I'll find it here. Do you have a specific link for me to check?