General and Desktop

I need to do something like this @QScriptValue(QScriptEngine *engine, &bool val);@

QNetworkReply does not implement the waitFor* methods (and: they do nothing in the base class implementation). You must use the async interface. The QEventLoop is a nice trick but may pose other problems.

.

Yes, it can be done. You can make your QGraphicsView basically work as a QAbstractItemView. But it will be up to you to handle all that. I have build something like that in the past. The application had a tree view, a graphics view and a property editor all representing the same data store. They were all just different representations of the same thing. However, I am not sure that QAbstractItemModel is the right interface for all of this. In my case, I choose to give my data store a QAbstractItemModel interface, but that was not the only interface. It also supported an interface that made the property browser easy to implement, and an interface to support the graphics-view based representation.

Thanks. It works well. I expected a solution based on QSplitter itself, feeling it should be related to splitter itself. not children :-/

As always: it depends. Is your file very long? In that case, you may want to read it piece by piece using QTextStream. If it is not too big, you can read it in one go, but I would still use QTextStream (it takes care of some potential issues for you, like line endings). For appending data (that is: adding at the end), you can open a file in Append mode. See QFile documentation for how to do that. Then you can add to the file. You can not insert in a file without rewriting it.

It depends... You may want to just put instances of your widget in a vertical layout on a QScrollView.

Qt is meant to write applications that run in a platform independent way, for the most parts. There might be some that will not be handled by Qt, e.g. if you want to do some stuff that is rearly used, like hooking system events and handle them instead leaving them to the system. Those things must be done in an OS dependent way. QT is no 100% OS abstraction, otherwise it would have to emulate all features that windows has and Linux not on Linux and perhaps on MAC, and vice versa.

With QSettings, you will have to either create your own engine for it (not trivial, I found out), or limit yourself to encrypting only the values and not the keys, and limit yourself to not using the more advanced features of QSettings for things like arrays. That sounds rather limiting and brittle to me, and it still gives away information on what is stored. If you are interested in securely storing settings, I would not rely on QSettings. Instead, I would probably go for a solution where I create a binary file with settings, using QDataStream. The binary blob resulting from that can then be encrypted and stored. The "SimpleCrypt":http://developer.qt.nokia.com/wiki/Simple_encryption class Lukas mentioned may help you with that final encryption, but do not mistake it for strong encryption. I should know: I wrote it :-) If you want something more strong, use OpenSSL or some other well tested and well designed library by crypto experts instead, and make sure you understand the pitfalls in using them (there are many!) However, if you just want to shield the blob with settings from curious eyes, then SimpleCrypt may be just what you need.

the bug report was created by szuzsq https://bugreports.qt.nokia.com/browse/QTCREATORBUG-6150

no,i just want to draw rectitem with mouse on the scene..

I think that if your element is a child of QGraphicsPixmapItem, your constructor must have an initialisation with some QGraphicsPixmapItem....

Here's an old link on the problem: "How to test if a file is already open":http://lists.trolltech.com/qt-interest/2006-01/msg00251.html

I found a "link":http://developer.qt.nokia.com/wiki/V8_Port here allaying most of my fears, concerns and heard rumors. Again respect for clear thinking ideas which are well communicated and documented. :)

If the above code is really in your GUI thread, and this is your timer, than forget everything about mutexes and the likes. You are not using threading, so that is not the solution. Look for your solution around your point 2.

You could query the qApplication->font(); at the start of the program, and save the font that is returned originally. Then you can keep it on hand for when you want to revert back to it.

Be sure and edit the thread topic to add [Solved] at the beginning. Thanks!

Whatever you define as "certainty"...