General and Desktop

Ryan: you have to take care of the "len" - parameters, they can change on every call. you could implement the buffer as some sort of circular buffer and check your write and read positions ... this should work: @qint64 myProcessing::writeData(const char *data, qint64 len) { qint16* aVal; qint64 numSamples = len / 2; qint64 posSamples = 1; aVal = (qint16*) data; while (posSamples <= numSamples) { mBuffer[mBufWritePos] = doSomething(*aVal); mBufWritePos = (mBufWritePos+1) % bufSize; aVal++; posSamples++; } mBufFill += len; return len; } qint64 myProcessing::readData(char *data, qint64 maxlen) { if (mBufFill<=0) return 0; qint64 toDo = qMin(maxlen, (qint64) mBufFill); if (toDo / 2 + mBufReadPos > bufSize) { qint64 firstNum = (bufSize - mBufReadPos) * 2; memcpy( data, &mBuffer;[mBufReadPos], firstNum ); memcpy( data + firstNum, &mBuffer;[0], toDo - firstNum); } else { memcpy(data, &mBuffer;[mBufReadPos], toDo); } mBufReadPos = (mBufReadPos + toDo/2) % bufSize; mBufFill -= toDo; return toDo; }@

Hi Leon did you look at tzhe fiunctions I pointed you to? QTreeWidget::setHeaderItem QTreeWidget::setHeaderLabel QTreeWidget::setHeaderLabels [quote author="Gerolf" date="1311327187"]You can use "QTreeWidget::setHeaderItem":http://doc.qt.nokia.com/4.7/qtreewidget.html#setHeaderItem or some similar functions.[/quote]

You should google a bit on "Qt webserver". There is plenty of code to be found that goes into the direction you're interested in, but as peppe said: QNAM and friends are geared towards the client end of business, not the server end.

Thank you for the reply! And what's more it worked like a charm! Thanks a ton! BR Rupesh

You might want to step up and add the feature yourself, after which you can request it to be merged into Qt.

[[Doc:QDirIterator]] is also worth taking a look at, depending on your use case.

If you don't want to use Qt and Qt datatypes in your win32 console application, then your library methods should not return Qt data types. So, either: Link the win32 console app to Qt Core, and be able to use the Qt data types, or Do not use Qt data types in your library API but limit yourself to standard data types.

Bugs are not covered in the docs. You could file a bugreport in the "bugtracker.":https://bugreports.qt.nokia.com/secure/Dashboard.jspa If you feel your experience/workaround can help others, please add it as a doc note.

bq. Example: Original file http://dl.dropbox.com/u/6552350/buy_one_free.wav This is how the distorted file sounds: http://dl.dropbox.com/u/6552350/distorted.wav I tested both on windows 7 and as you said I can play them. But on iOS 4 the first couldn't be played. I know that's not a solution to your problem but could be interesting te know. "Did you follow the following installation instructions ? ":http://developer.qt.nokia.com/doc/qt-4.7/phonon-overview.html#id-13ad5cd8-5ffa-4fdb-b3ec-a6a0bd57e92b bq. On Windows, building Phonon requires DirectX and DirectShow version 9 or higher. You'll need additional SDKs you can download from Microsoft. "Also did you know this about Phonon":http://labs.qt.nokia.com/2011/05/12/qt-modules-maturity-level-the-list/ bq. Overall module state: Done inside Qt, Maintained outside of Qt Reasoning: QtMultimediaKit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community. It could be worth a try using QtMultimediakit I couldn't find a similar bug in the "bugtracker :":https://bugreports.qt.nokia.com/secure/QuickSearch.jspa You could add your bug report if the above requirements are met.

yeah I have already done this with QWidget::keyPressEvent() and other sub-event functions but it just did not dawn on me that I was cutting of all sub events() by reimplementing event(), I simply considered that both the event and sub-event functions would get called.

I was reading some moc related material today, and this was one point that I came across.. http://doc.qt.nokia.com/latest/moc.html see under "Limitations" section.

I ended up adding these lines to the .pro file: QMAKE_EXTRA_TARGETS += buildNo buildNo.commands = ./buildNoScript PRE_TARGETDEPS += buildNo # adding this removes the necessity to use .target Then I made a simple script called buildNoScript that calls a small program that updates build info in a file (it reads the build no from that file first then increments it and writes it back).

Well, I've put [Solved] since I worked around it. But at least thanks for this very clear hard and fast rule. This would've spared me the experimenting.

Sorry, the painter is useless, I solved the problem. Here's the solution if some are interest : @ QPrinter Printer(QPrinter::HighResolution); QString htmlText(Text->toHtml()); QPrintDialog PrintDialog(&Printer;, this); if (PrintDialog.exec()) { Printer.setFullPage(true); QTextDocument TextDocument; TextDocument.setHtml(htmlText); TextDocument.print(&Printer;); }@ tha,ks

I think it needs a lot of work, anyway thank you Andre, that's what I was looking for.

Here's one way to do it: Make your item selectable (setFlag()) If the item is selected, have your custom item class paint a resize handle in each corner and edge In your custom item class, override the mousePress(), mouseMove(), and mouseRelease() virtual functions. In the mousePress() function add code to check if the mouse press is over one of the handles. If it is set a flag that says you are in "resize mode". In the mouseMove() function, if you are in "resize mode" then resize (and maybe reposition) your item as determined by the moved amount. Remember to call prepareGeometryChange() to ensure the item gets repainted. In the mouseRelease() function flag that you are no longer in "resize mode". HTH.

Could you show the class definition and the constructor? (or all the code, if you're at it, a zipped project is always good).

I think you "have to read this :":http://doc.qt.nokia.com/4.7/qwidget.html#font-prop Especially this paragraph : bq. The current style, which is used to render the content of all standard Qt widgets, is free to choose to use the widget font, or in some cases, to ignore it (partially, or completely). In particular, certain styles like GTK style, Mac style, Windows XP, and Vista style, apply special modifications to the widget font to match the platform's native look and feel. Because of this, assigning properties to a widget's font is not guaranteed to change the appearance of the widget. Instead, you may choose to apply a styleSheet. Also the "QFont docs":http://developer.qt.nokia.com/doc/qt-4.7/qfont.html will explain this behaviour. In short : Qt tries to solve font issues for you that are not set by your theme/OS.