General and Desktop

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.

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...