General and Desktop

What platform are you running on ? If you are on Linux/Mac OS X you should try to run a profiler such as Valgrind to figure out where your application is spending cycles and figure out what your bottleneck is.

Ok I found the problem...and it was a stupid one. In the last line of my MLAutoCompleterPopUp::event() I was calling the QWidget::event for all the events different from a tooltip request...but QListView reimplements his own event so I have to call it instead the one of QWidget.

Thank you for the reply; Yes, I am calling update() rather than the PaintEvent directly. I tried a similar idea tot he one you suggested without success, but i think Ive just found the real problem with the program: it has a memory leak that only became apparent when the paintevent got called frequently enough. I have now identified the problem in the code half way through writing this reply: when I remove all the painter.save(); commands there is no longer a memory leak :D so just to detail what I done in the last half an hour: 1.) removed all the painter.save(); functions which dont appear to be necessary This gave continuous "QPainter::restore: Unbalanced save/restore" errors in Qt. (which is why I put the save() functions in to start with) 2.) remove all the painter.restore(); functions (these were only there because I copied the example, as with .save() I dont truly know what they do) 3.) enjoy a program that functions identically to before but without memory leaks and without warnings in Qt. For reference It would be nice to know how to stop this problem if it ever happens that you need the save/restore functions. Cheers, Woody

It's up to you what happens inside your implementation of QAbstractItemModel::dropMimeData.

Additionally, using QtWebKit with statically compiled Qt is not supported.

Thank you ! I will try in this way !

[quote author="Lukas Geyer" date="1323420960"]Well, QByteArray actually is a BLOB ("The QByteArray class provides an array of bytes."), so why should it be stored as anything else then a BLOB?[/quote] Correct, even if this example they are not Large...sounds as they should be stored as BOB! Just joking.

Thanks for your quick, concise and right answer. I did it exactly as you suggested and it works like a charm. Thanks again Volker.

Solved! I used update() in a separate function/ slot. Thank you! :)

Nevermind. I was converting integers to strings using a stringstream and forgot to clear it afterwards. I think I've got it working.

No problem. Don't hesitate to ask - we seldomly bite :-)

Another option would be small text files that you put into a resource file (.qrc). Either make one resource file for each language or make a subdirectory for each language.

Sorry, I don't have a clue why the auto completion doesn't work. I'd suggest to start a separate thread in the Tools forum, where the Qt Creator guys may catch up.

No problem to stealing my post, as long as it is profitable for all, and after reading your question, yes it is profitable. It is a good point and thanks to Andre and Volker for their answer. I will go with the first from from now on, to avoid a lot of corrections in the future when porting applications to Qt5 [quote author="sierdzio" date="1323324830"]I'll kind of steal your topic, if I may, Patrick. Please? OK, what I am, and always have been, curious about, are the "nested" includes like: @ #include <QtCore/QString> @ Are they any different from simple: @ #include <QString> @ ?[/quote]

Thank you all, now its working fine

Yes, I had checked the format of the dropped data and indeed on Windows/Mac OS X, the data had a text/uri-list format while on Linux it also had text/plain format. Anyway, for some reason, your message made me think of dragEnterEvent and testing the format of the data there, and decide whether to accept the event or not. In other words, I have created a new class which inherits from QsciScintilla and which overrides dragEnterEvent: @void QScintilla::dragEnterEvent(QDragEnterEvent *pEvent) { if (!pEvent->mimeData()->hasFormat("text/uri-list")) pEvent->acceptProposedAction(); else pEvent->ignore(); }@

That improved the performance a lot. Thank you!

I feel stupid... This particular part was used as a component, and used by one instance where the model hadn't been set. This was called first so it always seemed to crash at this call, though the reason wasn't the object I suspected.. :P Thank you for making me dig deeper! -Richard

Try this: @ setAttribute(Qt::WA_StyledBackground, true); setStyleSheet("QWidget { background-color: #FF0000; }");@