General and Desktop

Volker: Thank you for this info, I will certainly try to remember this from now on........ Thank you all for all of your responses.

No, not that I know off. But you could make your delegate just expose the default behaviour for all cells that do not match certain criteria.

KDE's Solid API (which is implemented on Linux, Windows and Mac) has the concept of a Device UID. That is basically what you seem to be looking for, and it is appearantly feasable to implement that on all the platforms. Note that if you want to list the storage media on the system, you can also use Qt Mobility SystemInfo API' s (also works on the desktop!) to list the devices, and get access to the URL's they reside on.

The big question is: why do you do this? Why make your socket handling first asynchronic by putting it in a thread, and then use synchronic programming again within the thread? Why not use the asynchronic programming methods directly and get rid of both the thread and the waitFor* methods?

Now it works, thank you!

In genereal, it works with beginResetModel / endResetModel if you change the whole model. If you update a value, use dataChanged signal. If you only insert a row or a column, use beginInsertRows() and endInsertRows, resp. Columns.

Just keep pointers to your Actions in MainWindow class and change Actions state on QTabWidget::currentChanged ( int index ) signal

[quote author="ahmed kato" date="1318231015"]so i have to add qgif.dll with other ddls and make a directory for images...even i am using resourcing system??[/quote] Short: Yes. No. Long: Yes, you will have to deploy the imageformats plugins. That's the code used by Qt do decode the image bytes into something actually displayable. That's always needed, regardless of where you store your image data (file system, download from the net or the qrc resource system). The plugin has to go into the subdirectory imageformats. No, you need not to distribute your actual images (GIFs) on the destination machine. This data has been included into the application binary by means of the qrc resource system.

No, no, no. To cite wikipedia: [quote]In computing, the term endian or endianness refers to the ordering of individually addressable sub-components within the representation of a larger data item as stored in external memory (or, sometimes, as sent on a serial connection).[/quote] That is, the endianness only applies to the internal ordering of the sub-components of the data representation. It does not apply to the ordering of these subcomponents within the data representation itself. The order of your data stream itself is not changed anywhere, or by anyone. It will stay as it is. If your data is written in the order parameter1, parameter2, parameter3, they will stay in that order and should be read back in that order, no matter what endianness was used in writing. The endianness only applies to the byte ordering within these parameters. Reflect a bit on what would happen if it applied to the whole data representation in the case of working with a large data stream (say, a HD video streaming service). Do you really think that in case a little-endian prepresentation would be used, the whole datastream needs to be transferred to the client before that client can start processing it? You think that the first frame of the video on that stream will be at the end of the stream? That would not make a very good streaming service, would it?

thanks you all. i got it working. i slightly modified my "qtenv2.bat" bat file in PATHTOQT to include visual studio things "call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86" regards Deepak

So, don't use an empty definition, but use @ void MyButton::paintEvent(QPaintEvent* pe) { if (do_own_drawing) { //blah, do the drawing } else { QPushButton::paintEvent(pe); //assuming your button class inherits QPushButton } } @ By the way, did you know that you can also customize the rendering of exiting buttons using style sheets? Not sure what you want to achieve, but that might be easier if you just want to modify the rendering of the button.

Thanks. I agree that is indeed necessary to recognize when to use the right facility, and that inheritance is a quite strong mechanism. In my case the temptation is high: I've to develop a set of widgets that will act exactly the same and change only in their initialization data, so having to provide signals to simply re-implement the same logic in all of them seems to me quite odd. However I was curious to know how you develop in such situations, and of course, it is often quite simply to convert a slot connection to a signal (refactoring). I am aware of the tricks to pass back a signal-processed value, but as you state they are not very portable and, most notably, not thread safe. I guess such implementations should be avoided for normal application and should be used only when developing a much complex framework.

Thanks a lot my friend! Now I have a better understanding how signals/slots work with threads. Thank you! Cheers!

iv used phonon before ill go try and work with that :D

how to add the same thing to dockwidget

You are correct. I'm such an idiot. LOL Thanks!

done ;)