General and Desktop

Getting the right ID is impossible until you actually add the row in the database -- you COULD ask the database for the next value, but nothing prevents other users to perform inserts in the meanwhile, thus incrementing the counter. I'd say it's better for you to show a dummy value for that column (possibly greyed out or something), and show the right ID only after you performed the insertion.

mySettings.value() returns a QVariant. So you clear the contents of the returned variant, not the settings. You should try: @ mySettings.remove("code"); @ This removes the key and its value from the QSettings object. A sync() is not necessary.

Be sure and update the thread title to add [Solved]. Thanks!

[quote author="SamFaye" date="1314899811"]This is because the other instructions are executed while the server response is not received. How to wait for the server response to continue execution of other instructions?[/quote] Which other instructions? QNAM emits the finished signal when the response is available. This is where your response handling code has to go. Blocking your application until data is available is usually not the solution, it just covers a severe design flaw.

Happy to hear that is works. Rgarding the question that the command work anywhere, it is possible that I don't remember in what case it doesn't work. But it doesn't matter, it was just a reminder that the command exist also if in some conditions it does not appear. Note that regadless where the file are they are put in sources, headers, other files etc. depending by the kind of file your are adding to the project. Cheers.

That's solved! I didn't know i have to read everything every time in order to avoid infinite signal emission. Thanks a lot.

Issue was solved: Downloaded PostgreSQL 9.0 and re-built the Qt PostgreSQL driver with 9.0's headers and libraries. Now I can make SSL connections to PostgreSQL.

That's because those measurements are in local coordinates. ie the item width never changes in its own coordinate system. I think you need to transform the item's bounding rect by the total transformation and see if the resulting rect is small than the view's viewport size.

Have at look at "scopes":http://doc.qt.nokia.com/latest/qmake-advanced-usage.html#scopes in the qmake manual.

The object oriented pattern is called "singleton". And it's object oriented design to get that singleton instance by means of a static method of that class, and not by some unrelated other class. You will need the Q(Core)Application method anyways, as you can have an instance of that without any widgets. So no, an getApplication() method for QWidget, does not make any sense.

The problem is indeed comparing an iterator with a const iterator, which is not easy to prevent in C++03. The correct code should be: @ ResultConstIterator entry = getIterator(checkArray, nr); ResultConstIterator constEnd = checkArray.end(); if (entry != constEnd) { doSomething(entry); } @ QVector::end() does a detach() resulting in different end pointers. With QVector constEnd() can be used, and C++11 has cend().

[quote author="Gourmand" date="1314865363"] bq. thread affinity has absolutely nothing to do with plugins Threads affinity itself - ok, nothing. But to organize data exchange between threads in different plugins lots of additional coding needed. Signal/slot is most useful ready made system for this. I need exchange not only QStrings - but all possible data included into QVariant. [/quote] You have a thread problem. It is completely irrelevant if that is caused by threads created by some plugins or by threads from on single application binary. A QThread is as QThread, it even doesn't know if it's from the main app or a plugin. If you're not willing to invest some minutes for a good test case, why should we bother wasting our times for solving so called "problems" for you? You may want to read "here":http://www.catb.org/~esr/faqs/smart-questions.html and understand why if you do not get the rationale yourself and if you can spend some secondes of your valuable time to read such stuff. Good luck with solving your problem, though.

[quote author="RainWhisper" date="1314858814"]bq. You can call endEdit from your event handler then. This will not help me because I check the flag straightforward in the same event handler.[/quote] Then call endEdit before you check the flag. Or add a public method @ bool MyTableView:isEditing() { return state() == QAbstractItemView::EditingState; } @ If it returns true, you are editing the cell, and thus committing the change to the model will have the model be modified. Another alternative is to save the modified state in the model and check that before your ask-back code.

yes i know. i made a mistake when i posted the message about understanding qt a bit more. i should have said c++.

Well, I subclasses both of those, made a function to return the pointer for their lineEdit and installed the event filter, still not working =[ I'm about to sleep, I'll study more regarding these QLineEdits tomorrow. Thanks anyway

I tried to use the Model View system to make it work, but it gave me more headaches than solutions. QTableView::setModel is private so I couldn't make it work with the table I had. Now it is working, what I've done? Filtered the QEvent::FocusIn to force the Cell selection, here goes the code: @bool Dialog::eventFilter(QObject object, QEvent event) { if(object->isWidgetType() && event->type() == QEvent::FocusIn) { QWidget widget = qobject_cast<QWidget>(object); if(widget) { ui->table->setCurrentCell(widget->pos().y() / 30, 0); } } return false; }@ I'm using that stupid way to select the cell because it was not working with "the proper way". The cells height are constant so a temporary solution for a short on time project. I'm glad this is working, but I found what I've considered an error, maybe from Qt. I created a topic to discuss it: "link":http://developer.qt.nokia.com/forums/viewthread/9323/.

Hi, I did a QCoreApplication::sendPostedEvents after each signal-slot connection. That really made the trick. Why did this solve my problem? Thank you for the clue, peppe ;-) Cheers, Ole

How are you doing it? And which OS/WM are you using? (Now that I reread those methods docs, they mention the equivalent counterparts in QLayoutItem... perhaps it's something good to investigate).

Please provide a compiling & working program showcasing the issue.