General and Desktop

I use a embedded board i've resolved with QWidgetdesktop :)

"Contributing":http://qt-project.org/contribute is always a good idea! ;-) However, contributions have to follow the "contribution guidelines":http://qt-project.org/wiki/Qt-Contribution-Guidelines, both style-wise and design-wise, so make sure you've got in touch with the "maintainer":http://qt-project.org/wiki/Maintainers or the developer community ("IRC":irc://irc.freenode.net/qt-labs, "mailing list":http://lists.qt-project.org/mailman/listinfo) to discuss if such functionality is most likely to be accepted and how it is implemented the most beneficial way before starting any work. I personally think that having an option to provide visual feedback on failed validation is quite a good thing. This can be as easy as adding a textRejected() signal to input widgets supporting validation, but this is an implementation detail.

Thanks, Good eye! I also noticed that I was referencing the wrong button. It is giving that style when the button is unchecked, not checked.

rschaub I tried add this line too but nothing... I pasted my code (simplified) "here":http://paste.ideaslabs.com/show/npRYMkeMqC if you want to see it in detail.

For simple situations like this, you can use the "Browser for QDebug Log Output":/wiki/Browser_for_QDebug_output as presented in the wiki. It basically opens a [[Doc:QTextBrowser]] in order to display the qDebug() output. I made it for my own project because of the lacking debugging facilities on the console on Windows :-) If you need something more sophisticated, there are full featured logger frameworks ready to use out there.

As soroush already suggested TCP is probably better than UDP. Especially if you have dedicated connections. TCP makes sure that the information is being received. UDP is for broadcasting from one server to a number of clients, but it does not care that the info is really received. If you are looking for a start, there are "the network examples.":https://qt-project.org/doc/qt-4.8/examples-network.html A good start are the "fortune server":https://qt-project.org/doc/qt-4.8/network-fortuneserver.html and the "fortune client":https://qt-project.org/doc/qt-4.8/network-fortuneclient.html examples.

It's not that the message isn't welcome here, it's more that you'll find a more focussed audience at that mailinglist. Thank you for your efforts! I was wondering what your suggestions mean for QFileSystemWatcher. Do you propose to change the implementation of it on Linux to use your notifyfs instead of the current situation, and leave the backend implementation as is for Windows and Mac?

I wrote some multi-threaded application in Qt using MySQL database before. There was no problem. Documentation says that the class is not thread-safe (does not implement move semantics, by the Qt way) I think there should not be any problem if you're using a DBMS like MySQL. because the DBMS can handle multiple users connected to a db in same time. You should only take care of logical order of operations in your program. For example, before creating a table by a thread, other thread should not query some data from it. or before opening connection to a db by a thread, any other thread should not try to interact with db. In the case you where ysing SQLite, your database is a normal file on the disk. So problems may occure.

I'm unaware of this bug, but you can circumvent it by using something similar to @ void CMyBackgroundWidget::focusInEvent(QEvent*) { m_pMyForegroundWidget->raise(); } @ the "raise()":http://qt-project.org/doc/qt-4.8/qwidget.html#raise will move the foreground widget to the top of the hierarchy and display it there. Note that m_pMyForegroundWidget should be on the same hierarchy level as the instance of CMyBackgroundWidget. If they're descendants of each other, this fix won't work.

for that, you'll have to either implement an "eventFilter":http://qt-project.org/doc/qt-4.8/qobject.html#eventFilter and "install it":http://qt-project.org/doc/qt-4.8/qobject.html#installEventFilter, or reimplement the "keyPressEvent":http://qt-project.org/doc/qt-4.8/qwidget.html#keyPressEvent on a QWidget. The event you'll get in either of those two methods will hold the currently (or at the time of the event) pressed key.

If I have this code in a QGraphicsRectItem class: Private: @ QGraphicsRectItem *item; @ Constructor: @ item = new QGraphicsRectItem(); @ mousePressEvent: @ this->addItem(item); @ mouseReleaseEvent: @ this->removeItem(item) @ Do I must delete the item in the destructor, because the item is not a child of the scene ( this->removeItem(item) )?? Destructor: @ delete item; @ [quote author="cincirin" date="1337071681"][quote author="Mariø™" date="1337040692"]Thanks, you solved my doubt. [quote author="MuldeR" date="1337039636"]I think you can design the constructor of your "Item" class as you like. If you never want to set a parent for "Item" objects, then you don't need to have the "parent" parameter in your constructor, of course. You can't change the constructor of QGraphicsItem, because it's a pre-defined class from Qt. But, as the definition of QGraphicsItem has a default value for the "parent" parameter, you don't need to have QGraphicsItem in initialization list of your Item constructor. The QGraphicsItem constructor will simply be called with a NULL parent.[/quote] [/quote] Note that if parent is 0, you need to manually add item to scene ( QGraphicsScene::addItem() ), and of course item will be top level.[/quote]

Hi DerManu.. thanks for your reply. My game is just an OpenCV Qt integration project for a computer vision demo. I dont care much about being able to run it on another PC, but I will keep your suggestion in mind in case I proceed with developing this into a full-fledged game.

I think if the QUrls needs to designate an existing file you should just check for that with QDir::exists. This will return false as well when the Url does not have a valid format. QUrl::isValid will only test that the url follows the url format, not that it actually points to something.

Unfortunately no. I was hoping someone in the Qt community would have an answer.

You will have to distribute the necessary .dlls with your .exe. The only way around this is to statically link. Statically linking is (usually) not preferred because it leads to large .exe files, which are difficult to update. In addition, it causes license issues, as you are including source with different licenses. If you really want to statically link, do a google search for QT Designer static link and you'll find tutorials on how to set it up. If you make the choice to stay with dynamic linking, I recommend (and so does QT) using Dependency Walker, which can be downloaded for free. It will tell you all the dlls that the application needs. The QT libraries will be in your QT directory. If you compile with mingw, you'll want the dlls from C:\QtSDK\Desktop\Qt\4.8.1\mingw\bin (or something similar to that). If you compile with VS, you want the dlls from C:\QtSDK\QtCreator\bin mingw will also require two dlls in order to run programs in windows. These can be found in the same directory structure, C:\QtSDK\mingw\bin

Did you see already the "fortune examples here? ":http://qt-project.org/doc/qt-4.8/examples-network.html The "fortune server":http://qt-project.org/doc/qt-4.8/network-fortuneserver.html and the "fortune client ":http://qt-project.org/doc/qt-4.8/network-fortuneclient.html are a good place to start.

I don't see any reason for this in the code you've provided. You either run your code in debug mode to actually find out where it crashes or you post a small, compilable example that reproduces your problem so we can take a look at it.

Did you add @#include <ActiveQt/QAxObject>@ to your source code and @CONFIG += qaxcontainer@ to your .pro (qmake) file?