General and Desktop

I am still would like feed back and am curious to any of those who have had prior experience with the audio api of Qt. Therefore, would it be suited for what I am doing (such as implementing an equalizer while maintaining quality play back) or would I be better to account for each platform I am developing for?

Hi Vijay, the server operating systems are not officially mentioned on the web page for the supported platforms. But from my experience, I can tell you, it's no probelm :-) Server 2003 is equivalent to Windows XP (kernel side) and has more features for sdervers. Server 2008 R1 is equivalent to Windows Vista Server 2008 R2 is equivalent to Windows 7. So if you look for the corresponding desktop systems, you see where it is supported and up to now it works on the corresponding server systems. Regards Gerolf

The space around them is controlled by the spacing parameter of the layout. Change that property in your layout to 0.

I concur with Gerolf: Get yourself legal advice if you want to be sure (or, perhaps, contact Digia sales department on this) LGPL should fit, as it does not restrict the licence of the work derived from the library. That means you can choose a closed licence (as is most often done), but it should also mean that you can choose a very liberal licence like you plan to do. It is my, non legal opinion that LGPL allows static linking as long as you provide some other means to satisfy the LGPL requirement that it must be possible for the user to replace the version of the library used (so, that means: relink the binairy).

I would indeed subclass QStyledItemDelegate, and reimplement the createEditor method to something like this: @ QWidget* OneLetterDelegate::createEditor ( QWidget * parent, const QStyleOptionViewItem & option, const QModelIndex & index ) const { //let QStyledItemDelegate do the hard work and create an editor QWidget* widget = QStyledItemDelegate::createEditor(parent, option, index); //If the editor is a a QLineEdit, we apply our limits: QLineEdit* lineEdit = qobject_cast<QLineEdit*>(widget); if (lineEdit) { lineEdit->setInputmask("a"); } return widget; } @

it works! i thought that it was more complicated. thanks

The same is true for many other Q_* "macros". They actually expand to nothing in the preprocessor. They are special keywords used by the meta-object compiler to indicate that it needs to generate some code there.

Much thanks Volker. I implemented something similar to override my problem but not nearly as detailed as your solution.

use (spot the parentheses after the <int>). @ qSort(rows.begin(), rows.end(), qGreater<int>()); @

Yes, you're right, sorry. I have it in a QXyzView subclass and thus can call slot currentChanged() this way.

Use setSelectionMode() to the mode you want. See the documentation for QAbstractItemModel for details (base class of QTableWidget).

WOW... I feel so much better now. Thank you all! No more errors and I actually know how things work :)

I split off this question into it's own thread as it was completely unrelated to the previous discussion in the "old thread":http://developer.qt.nokia.com/forums/viewthread/4645 Please open a new thread in the correct forum if you have new questions, don't just reply in any old thread.

At a guess I would say defining that variable prevents Qt from using the XRender extension. ;-) The XRender extension allows certain graphic operations to be accelerated. However, actual driver support for XRender varies and often XRender still hits code paths that are not optimised/accelerated by hardware. I think that this was one of the reasons why Qt has concentrated on the raster graphicssystem as opposed to the X11 one recently. To try the raster graphics system, you can specify an option on the command line like this: @./myapp -graphicssystem raster@ This option can also be compiled into Qt as the default or enforced by the application itself via a call to QApplication::setGraphicsSystem( "raster" ).

It is not possible to give memory from one process to another directly. The address spaces are separated. You can use some IPC mechanisms to communicate between them, but the resources stay in the process where they are.

If you have any further questions, just ask. It was a short shot, but it will work :-)

What's the recommended way? I'm not sure. Perhaps you could copy the framebuffer to a texture, manipulate that, and copy it back to the framebuffer.

Sorry, I guess I didn't understand at first, but you are correct. -Thanks The following worked: @MainWindow::MainWindow(QWidget parent) : QMainWindow(parent), ui(new Ui::MainWindow) { ui->setupUi(this); QScrollArea scrollArea = new QScrollArea(); this->setCentralWidget(scrollArea); //create the widget with elements that require scrolling to view QWidget* widget = new CustomWidget(); scrollArea->setWidget(widget); } @

in your header you need to include the lines @namespace Ui { class dialogEmail; }@