There's no need for any global objects all the more if you only have one active connection for your application but it's also valid if you are managing multiple connections. The QSqlDatabase class already provides everything you need.
Like written in the documentation, if you are only using one connection, don't give it a name, it will become the default connection and all the SQL related classes will use it by default.
If you have several connections, it's easy to retrieve the one you are interested in by using QSqlDatabase::database.
On a side note, you should properly test the outcome of your open call. Right now it could be failing and you don't care about that possibility.
Put a QSortFilterProxy model in-between. then save from the proxy instead of the main model.
connect(currentTableHeader, SIGNAL(sectionClicked(int)), this, SLOT(on_sectionClicked(int))); and void mainWidget::on_sectionClicked(int index) are useless. this is the default behaviour of QTableView, you don't have to implement it manually
How do you know that A, B and C are equal to 0? If they are, then your program will give error when you click on "calculate" - "Division by zero".
Could you put some debug statements in your code?
qDebug() << "A: " << A << "\tB: " << B << "\tC: " << C;
delta = ((B * B) - (4 * (A * C)));
@joeQ As it turns out, I just tried the opposite. I had one newed Message Box for everything. In the place that had the funny location, I made a separate newed Message Box and it ended up in the correct place - the middle of its parent.
@diredko Why passing it once using a normal function (Q_INVOKABLE) would hurt performance in your opinion? It would certainly be more efficient to have a big list in QML than use a function again and again, and such a list isn't big for modern hardware (couple of hundreds of KBytes maybe). If you can afford to have that list in C++ you should be able to afford to have it in QML, too.
I think the biggest performance obstacle is that the system isn't real-time, QML may do garbage collection and animation isn't fluent. I recommend just testing with the most easy solution in the lowest end hardware it will be run on and deciding after that if it's enough.
After a detailed research of various asynchronous techniques such as Promises, Futures, Tasks and Reactive Extensions we came with a new paradigm that solved all our asynchronous problems very elegantly: The Streams Paradigm
It's inspired by the reactive approach, though superior in many aspects such as abstraction, abortion, resumables etc.
It's a completely rethought way of writing declarative code, making complex asynchronous operations and transactions (and probably even concurrency) a piece of cake! Nearly everything can be represented, thus abstracted away by a stream..
Requests (HTTP etc.)
the list goes on...
This way streams become a consistent protocol of asynchronous and concurrent communication between various application components ranging from the UI frontend to the networked backend.
We published the first beta release of a QML implementation with a working example aboard, be sure to check it out!
We are a company from Ukraine. We develop different devices include ultrasonic devices.That's why we have experience developing software for microcontrollers STM32 and Qt software. We have experience om Windows Ce embedded. I read that you need only employee job. But I think we can discuss our opportunities.
Thanx a lot,
OK. I found it. I was being dumb! I have two flavors of Progress Dialogs. One is inside an App, and the other is standalone, meant to be called form a script. I was looking at the one in the App when I should have been looking at the other one. The standalone one doesn't have have a cancel slot.
@ganeshkbhat Allowing to load and run 3rd C++ inside your main applications's process is very dangerous and we have not found any easy way to sandbox C++ so far, only just have a few ideas worth trying. I've described this issue here in a little more detail.
Sorry, I meant the second code block, not the first. I'm not very familiar with assertions in general, so I've never heard of Q_ASSERT.
The assertion here is only a tool to detect creating more than one instance of the class. Q_ASSERT is a Qt macro for regular debug assertions, it will be removed in release mode, so its purpose (as assertions in general) is to catch programmer errors while debugging. So if you use the class above like this:
Singleton object2; //< Here the assertion will be tripped and you can catch the error while debugging
Adding the code in the second block fixed the issue.
Do you mean the main window constructor where the connect is made? All code blocks are part of one single example, so I'd expect them to work together only. :)
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.