General and Desktop

I think using "QxtItemDelegate":http://libqxt.bitbucket.org/doc/0.6/qxtitemdelegate.html is a much better solution...

A Q_PROPERTY can be seen as doing two things (IMHO): It adds a semantic meaning to a set of methods (a getter, and possibly a setter, a signal and/or a reset method). This tells the user of your API that these all belong together. It acts as a kind of documentation, which is a Good Thing(TM). It adds introspection capabilities for your property. The flags you can add to the property help at that task. This also makes it possible do things like @ myObject->setProperty("foo", someValue); @ I find the first to be the most important, though the second can bring real technical benefits as well, especially when you want to expose your classes to scripting, for D-BUS or to QML.

[quote author="Volker" date="1340534251"]But I would advise to open a bug report on "Jira":https://bugreports.qt-project.org/, including your special test case.[/quote] Okay, will do that. [quote author="Volker" date="1340534251"]I'm not sure if it will be fixed in the Qt 4 series, as one might argue that it could break backwards compatibility. But at least for the upcoming Qt 5 this should be fixed, IMHO (but I'm not a Qt dev, I have no power to decide this).[/quote] Yes and No. The exact behavior of Qt's internal command-line tokenizer would change, indeed. But the current implementation already is inconsistent with the C++ Runtime. That is: If you write a Qt-based Console application, your main() method will be called directly by the C++ Runtime, giving you the "standard" (correct) behavior. Only if you write a Qt-based GUI application and compile it with "qtmain.lib", your main() method will now be called from Qt's own dummy WinMain() function and thus you'll get the "non-standard" (wrong) behavior. If you do not use "qtmain.lib" and instead write a WinMain() function yourself, then you'll probably use GetCommandLineW() + CommandLineToArgvW() and also get the "standard" (correct) behavior. Consequently, at the moment, Qt already breaks compatibility itself - showing different behavior depending on how the binary is compiled. That is: Relying on the "old" behavior is unsafe anyway! IMHO fixing the inconsistent behavior would only improve things... BTW: The C++ Runtime's on Windows (MSVC) and on Linux (GCC) show the same behavior. The string "C:\Test''Foo''.mp3" is processed correctly. So Qt's tokenizer currently doesn't mimic any of those.

A style sheet should do the trick, I think.

You are welcome. Good luck and happy coding!

Thanks a lot. I was looking for an elegant solution like this.

Only one widget in my application requires specific actions on dragging by the left mouse button depended on keyboard modifiers state to do some operations on graphics objects. I have decided to enable mouse tracking for this widget and to call the grabMouse() function in reimplemented focusInEvent() and enterEvent() functions. To restore the default processing of mouse events I call the releaseMouse() function in reimplemented focusOutEvent() and leaveEvent() functions. If there are situations when some dialogs can be appeared then the following event filter @ bool GraphWidget::eventFilter(QObject *watched, QEvent *event) { if (watched != this && event->type() == QEvent::FocusIn) { QApplication::instance()->removeEventFilter(this); releaseMouse(); } return false; } @ can help to catch situations when the releaseMouse() function must be called. This event filter should be installed anywhere where the grabMouse() function is called: @ ... grabMouse(); QApplication::instance()->installEventFilter(this); ... @ May be there more preferred methods to prevent executing actions reserved by KDE or by other window management system and to execute custom action for own application on occurring specified events. I will glad if anybody propose other methods to do it.

First see if QSqlRelationalTableModel scratches your itch. Alternatively write your own QSqlQueryModel subclass that allows editing (see the query model example for a basic version). You might also see if writing through a MySQL view is possible and, if so, can solve your problem.

Thanks Volker. I still think that is still sort of badly designed... Let me add something else, I wish Qt created its own "framework" structure, which a qt user could then use to organize his project in a cross platform fashion... Perhaps with the ability to contain compiled binaries for a number of operating systems. I find it terribly annoying that Qt goes a long way toward cross-platform, yet it stops one step short...

you could use insertItem() instead of addItem() to add new items...

that is correct... although you might want to do it the other way round-QTextEdit::mouseDoubleClickEvent(e) after your code... in this case it doesn't matter, but in some cases it might

don't know about append()...but you can achieve what you want by this: @ QTextCursor *cursor=myTextEdit->textCursor(); cursor->insertText(stringToBeInserted); //...or cursor->insertText(stringToBeInserted,charFormatToBeUsed); @

First define your own QVariant for that handle type (see http://qt-project.org/doc/qt-4.8/qmetatype.html ), then use setData and data functions of QStandardItem to store/retrieve it, with an own type id, e.g. Qt::UserRole+1.

You're welcome. Please feel free to prepend your initial title with [Solved] to indicate that there is a solution inside.

I have solution QTextEdit::anchorAt()

Oh, I just forgot to mention another method: startDrag(). So this is what I have reimplemented in my tree view: "QAbstractItemView::startDrag() ":/doc/qt-4.8/qabstractitemview.html#startDrag "QAbstractItemView::dragEnterEvent() ":/doc/qt-4.8/qabstractitemview.html#dragEnterEvent "QAbstractItemView::dragMoveEvent() ":/doc/qt-4.8/qabstractitemview.html#dragMoveEvent "QAbstractItemView::dragLeaveEvent() ":/doc/qt-4.8/qabstractitemview.html#dragLeaveEvent "QAbstractItemView::dropEvent() ":/doc/qt-4.8/qabstractitemview.html#dropEvent

Purele speaking of Qt: yes, if the underlying mysql drivers support it. I'm not 100% sure, but as far as I remember, the drivers are backwards compatible, so you should be able to connect to an older server with a newer driver. But why don't you just try it in your current setup? Just fire up the mysql command line tool and try to connect...

You can use a [[Doc:QSqlTableModel]] and set it on a [[Doc:QTableView]]. I'll leave it to you to find the snippets in the two linked doc pages :-)