General and Desktop

I tried using it in the following ways but these did not work as well. QAbstractItemView::item { subcontrol-position: center center; } And QAbstractItemView::item::icon { subcontrol-position: center center; }

sorry, but include what?

Ok, setFrameShape did work actually. The other day I was running make from vi in the wrong dir. Thanks for the help. James.

Please check my "First post":http://developer.qt.nokia.com/forums/viewthread/595/ What is missing?

Great: the @LIBS += -lpsapi@ was the problem, it works now!! Thanks again, you make my day! I thought the @LIBS += -LC:/Windows/system32 -lpsapi@ worked, since no missing libraries error was found?

Hi, It works now perfectly - Thanks a lot.

yes, you're right Tobias, I was trying to follow the line of least resistance. My fault!

Thank you very much. Such a simple thing. I knew it had to be a moc thing I wasn't understanding/remembering. Thanks a lot for helping. I'm on my way again. Whooppee!!! :)

Link to whitepapers at ICS: "ICS Whitepapers":http://www.ics.com/learning/learning_center_downloads/ The whitepaper I mention here is named: Turbocharging Qt Applications You mus register at ICS in order to download it. Registration is easy an free ... Thats what is said about Windows and QT threading in this whitepaper: bq. Windows has its problems as well. While the underlying GUI libraries are in theory thread-safe (in practice, the so-called “consumer Windows versions” Windows 95/98/ME have stability issues with multithreading in GUI programs), memory management requires that you do not create any widgets or sockets (or anything else that handles operating system events) from any other thread than the main thread. I suspect that this applies to old Windows versions (9x). I myself use QUdpSocket at other threads than MAIN in WIN XP ... but I'd like to have some confirmation that it is really safe from someone who knows WIN32 api better than me:) I am trying to search for answer in internet but no results yet. Just found in many places that win socks are thread safe.

QFileInfo does probably exactly what Denis said. However, since someone else did the effort for you, there is absolutely no reason not to use QFileInfo.

I have found way to solve this problem: reset the relationship of proxymodel and sourcemodel

I guess I can also get edited data from delegate editor and insert it into database with a qsqlquery. But I even can't access to the editor. Any idea? Thanks

Thanks, for that good idea. Within QT3 I also implemented a subclass of QListViewItem and implemented "virtual int compare( ... )" but I didn't find this within QT4. Your first solution is very close to the one I used to have, so I've tried this and it works pretty well ! Thanks a lot for your help !

I don't think the order would matter wrt directx, directshow, winsdk. Let me see, I'll try to chk further and revert

Well, I didn't want to use the QSS, just so that I could keep it all in source(at least for now). It turns out I didn't do a few steps, for one, call setAutoFillBackground(true). That then filled in the background(not of the text, but of the line edit) red. So I changed p.setColor(QPalette::Base, Qt::white) to p.setColor(QPalette::Background, Qt::white) and it worked. I guess I misread the QPalette enum documentation. So it's solved.

Thanks for the answer, but nothing. Others codes works in QComboBox:!editable, for example @QComboBox:!editable { font: bold 10pt; }@ but for some reason color: white not I have a little clue, if the application lost focus (the entire application, not only the widget) the text become white, but when the focus is in the application again text changes his color, all the time the focus in the application is in another widget not in the QComboBox Any Idea?

Well, what shoud I say? Thanks for so much help! It really solves the problem.

any specific reason why you are not able to get access to file system? I think you could just use QPainter, set the appropriate QPaintDevice and also accomplish what you want to do. also from the docs: The drawing capabilities of QPaintDevice are currently implemented by the QWidget, QImage, QPixmap, QGLPixelBuffer, QPicture, and QPrinter subclasses. To implement support for a new backend, you must derive from QPaintDevice and reimplement the virtual paintEngine() function to tell QPainter which paint engine should be used to draw on this particular device. Note that you also must create a corresponding paint engine to be able to draw on the device, i.e derive from QPaintEngine and reimplement its virtual functions.

Oh, recompile... Again... :) Thank you! I use Win XP. And as I understand I should configure Qt with -qt-libjpeg key. Do I need something else to get it done?

@thomas, easier to read ur code if you enclose it in between @symbols