General and Desktop

Without a better idea of what you want, me neither, but this really isn't Qt related. That you make your GUI in Qt, does not make questions on what other libs to use on-topic here.

One way is to use a [[doc:QStackedWidget]], and create a page with a QTreeView for each of the items in your combobox. Then, let the selectedIndex of the combobox determine the currentIndex() of the widget stack. Or, if it really is the model in the view you'd like to change, do exactly that: use a single QTreeView, and simply add a bit of code to change the model you're using for the view based on the selected item in the combo box.

[quote author="TimS" date="1340692510"]Well I'm an idiot anyway because I just figured out javascript doesn't support native enum yet. Boy that is embarrassing. QtScript is great, just a steep learning curve as I'm looking to do complex stuff for my first project. Doesn't matter to me if it is just in maintenance mode. [/quote] There are no enums in js, because we don't need it there).

Signals are always protected from a technical point of view (only the class itself and its subclasses can emit them), and always public from a logical point of view (everyone can connect to a signal). The code you've posted works correctly. Make sure that you've included the header file mytextedit.h (no forward declaration) and that you've re-run qmake after adding the signal. In addition, you are missing a call to the base class constructor. @ MyTextEdit::MyTextEdit(QWidget *parent = 0) : QTextEdit(parent) { isEdited = false; } @

EDIT (the code I pasted before was wrong. In the post I can't write the code I used with escape character) . To let you see the code I write it with some space characters: html_document_str = " < img src= " :/images/intestazionegw.jpg " width="100%" > " ; The proble in my application is that if I put " width =100% " in my html code I don't see the image in the pdf while if I remove the "width" : html_document_str = " < img src= " :/images/intestazionegw.jpg " > " ; I can see the image printed in the pdf but its dimension is too big and go uotside the page.

I thought of this solution but did not feel as a clean solution. The problem is, the streamed XML data could be very large. So I have read all this into a large temp buffer and process. I wonder, Qt seems to provide a solution but it is not working as expected. Is there any technical difficulty implementing it? Thanks, Lloyd

I would rewrite it as something like: @ //a continuation of the main.cpp MainWindow *z = 0; window2 *y = 0; if (0 == access ("C:/Microsoft/add.txt",0)) z = new MainWindow(); z->show(); } else { y = new window2(); y->show(); } return a.exec(); } @ Brain to terminal; ymmv

i think this may be because of the QObject relies on QApplication's initialisation of various elements used by various features(such as signals and slots) although i can't say for sure

After you've got a new QDateTime, then you can use toTime_t() to get it back to unix time.

Thanks! Here it is!

There are also examples on the wiki. Some are quite basic, like "this":/wiki/Basic_Qt_Programming_Tutorial one.

Actually, it provides very strong encapsulation. You cannot access the d pointer as a user of the API, which is the whole point of encapsulation.

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&#39;'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.