General and Desktop

@Technologist Basically you were almost right with the images. Only an exclamation mark was missing ;) Here is the description

"Make everything as simple as possible, but not simpler" - Einstein I really like how simple and to the point your answer is. I am going to learn about it when i have time. Thanks a lot.

Well I might have not been entirely truthful saying a layout has no size. After all it is a QLayoutItem and, as you pointed out, it has a setGeometry method. What I should have said is you shouldn't think about a layout in these terms. There is rarely a case where you would manipulate a size of a layout directly or care about it at all, unless you're for example implementing your own layout, which is rare. You either change the size of the parent or the children and the layout with its (let's call it "virtual") size is a sort of bookkeeping mean to calculate the dependencies of parent and children. You can think of it as sorta "the magic that needs to happen", but I personally treat it as a publicly documented implementation detail :)

That caching strategy only works if your app is the only one accessing the database. There's no way for Qt to know if your database is modified frequently from outside or not. That said it just plays it safe by default and fetches the data again whenever it updates the view. As you pointed out though, it allows you to tweak that behavior to fit your particular needs (e.g. by implementing a cache, for offline access or any other type). Just remember that such cache can become stale if the database is concurrently accessed by other clients, so you might want to think of some way of checking that and discard the cache on some conditions. As to whether it's faster to fetch a row depends on the data itself and your access pattern. If you have a 1000 columns in a row, but the view covers just say 3 columns at a time it might be more efficient to fetch just part of the row or whole columns instead of whole rows. On the other hand if the table is "narrow" and the data is "light enough" fetching a whole row (or even a few rows at a time) can be better. There's no single answer that fits all scenarios. You'll have to profile and adjust to your particular case.

The solution was pretty easy, but I overlooked it: QBrush bgBrush,fgBrush; bgBrush = QBrush(color); fgBrush = QBrush(pixMap); painter->setPen(borderpen); painter->fillRect(rec, bgBrush); painter->fillRect(rec, fgBrush); painter->drawRect(rec); Just a brainfart from my side, nothing to see here. Move on!

Hi, AFAIK, and based on the doc, the record returned is populated.

I mean't: call the addStretch method form QXXXLayout

Hi, Are you creating a CSV file ? If so, QxtCsvModel might be an interesting solution. Hope it helps

You can open the file for writing and insert write QByteArrays to it via: QFile::write(const QByteArray & byteArray) Thus pick your favorite: QString::toUtf8() or QString::toLocal8bit().

Weight is an enumeration and theres a corresponding getter

Hi, Sounds like a good candidate for either the Graphics View framework or QML. The examples from the respective modules should help you get started. Hope it helps

Hi, could you also pastebin the licensevalidator.cpp file? Would help to spot the problem...

@sergboec Do the numbers come back in a "known" sequence upon each request? IE the first request gives #1, second #2 etc? If so you could still do a single ready read and just have a counter that serves to vector your received data to different handlers.

@JohnYork said: based on my experience, I think some warning comments should be added into Qt's API documents, to avoid the unecessaried mistakes on Qt newbies, just like me. Do you think so? It is tempting to want to place the blame on your framework or compiler however in my experience 99.9999% of the time it is the design or the programmer that is causing the issue. For the most part the code was exactly what you programmed it to do. What makes things harder now days is you really don't know how long an object lives when it is created in some strange place. Most objects in the framework have a parent pointer and when the parent dies or if you don't use parent (in some cases) and the object dies because of scope then all bets are off if you have pointers to that object. In the "old" days we pretty much managed everything ourselves. You created something, you had to get rid of it. Even with the newer ways of managing items I still find that at times knowing exactly when an object is valid and when it is not is invaluable. Therefore somethings need to be singletons that you create and leave around until you decide you are done with them. Anyway I doubt there is any comment that could be added to docs to help out with these concepts. The Qt docs document the use of the framework, not how to manage objects and object scope. Since those principles apply to ALL C++ objects a standard C++ tutorial, book or online course will give you what you need. This forum with the great people here can help to fill in the gaps on Qt related stuff. You'll find the people here amazingly knowledgeable and talented.

@jdla Dear, I'm going to answer my own question. Hope future readers will appreciate :) Apparently the timer event (timeout) is not generated when previous event is not yet finished. The quite simple fix is as follows : (i) make Calculation() a slot. (ii) invoke it as QMetaObject(this,"Calculation",Qt::QueuedConnection); Then the whole setup responds as expected, i.e. the timeouts are processed every 500ms, even if the calculation is still running. processEvents stays needed in order not to block the event loop.

Hi koahnig, you were right. I installed Qt in the "Program File" folder, and that was the source of my troubles. I reinstalled it in a "blank space free" location, and now everything works perfectly. Thank you.

Hi, internalPointer() is basically used when you use createIndex(). As I said the internal structure is not specified in the documentation; so if you want to understand the exact implementation you have to have a look in the Qt sources

Hello guys Thanks a lot for the answers. Your replies got me thinking and I recalled how includes can mess things up. I removed a couple of the include files in some of my header files that turned out to be unnecessary. After removing all the header files while still being able to compile then the program was running again perfectly. Regards Sebastian Aslund