General and Desktop

The following "FAQ":http://developer.qt.nokia.com/faq/answer/is_it_possible_to_move_the_qt_directory_to_another_directory_after_installa contains information on what you need to do when moving your Qt installation around.

See "format property":http://doc.qt.nokia.com/4.7/qprogressbar.html#format-prop you can add your text to this property and it will be show on progress bar

Many thanks for help!

[quote author="Andre" date="1309338341"]@Rajveer: QReadWriteLock does not work across processes, so it is useless for this case. [/quote] Thanks for the hint. I hadn't stumbled upon "QSystemSemaphore's":http://developer.qt.nokia.com/doc/qt-4.7/qsystemsemaphore.html up until now. Thanks for that hint too.

thats same problem with me, solved mine either.. thanks

Sorry it was smart installer. my mistake "Your text to link here...":https://picasaweb.google.com/lh/photo/8IdRKlR4hIEYObwGDdcZoQ?feat=directlink

the whole course of the discussion reminds me of http://xkcd.com/386/ :D wait()-ing in arbitrary places obviously will cause the caller to block until the waited thread is stop or finished. It is after all a blocking call. Waiting in other places of course after using the terminate () slot is another story, i.e. one can use this as a thread synchronization scheme in some corner cases. However if the thread is running for ever why to stop/delete it? If on the other hand the thread terminates eventually how are you going to know that it has terminated? (also relevant question is why do want it terminated - this will lead you to the sort of policy you are going to implement for its termination). [for instance , If you want to terminate it just for resource/performance reasons polling on the isFinished() is a bad idea, etc] however no matter what, prior to its deletion (obviously it has been terminated either by itself or by an external factor, otherwise why should we release the resources since it is still running via delete?), one has to call the wait() to see that the thread is ready to meet its maker. This is a quirk due to the different behaviour of the many OS after a request to stop the thread. This in most sane OSes (ie linux) will take less than one scheduler's time slot (that is usually in linux 10ms). That's the full explanation of my argument about wait(). One should use it when talking for the thread delete case, just to make sure that the thread has actually stopped (after he has learned that it has stopped (signal) or it has requested it to stop). /me over and out.

Thnaks for the advices Volker. Anyway, I'll stick with QTableWidget and will change all the presentation because QGraphicsViews messes with my head. I'm not experimented enough to work with it. Thanks

it would take only less than 30 minutes to do that. in desktop application select form and create two push buttons, right click on button and choose signal and slot(on Clicked()), it will provide you function where you can put your code to pass HEX or binary signal to COM port to set or reset.

<nitpick>nmake is not a compiler. It is just a tool that runs the actual compiler.</nitpick>

thank you for all your help. i will check this example :)

The below link is git repo for "Mobile Extensions" Symbian 4 project. It has got whole framework of QGraphicsWidget based widgets developed for mobile phones. Sadly its scrapped. https://qt.gitorious.org/uiemo/uiemo-preview/trees/master One place where you can find this QInputMethodEvent posed is... https://qt.gitorious.org/uiemo/uiemo-preview/blobs/master/src/hbplugins/inputmethods/common/hbinputmodehandler.cpp The software keypads code is at https://qt.gitorious.org/uiemo/uiemo-preview/trees/master/src/hbinput/inputwidgets and actual inputmethods ( QInputContext derived classes) is at https://qt.gitorious.org/uiemo/uiemo-preview/trees/master/src/hbplugins/inputmethods And HbLineEdit code which receives QInputMethodEvent is at https://qt.gitorious.org/uiemo/uiemo-preview/trees/master/src/hbwidgets/editors And https://qt.gitorious.org/uiemo/uiemo-preview/blobs/master/src/hbwidgets/editors/hbabstractedit.cpp handles some of inputMethodEvent events at line 244. And obviously one best place to study in Qt Source code it self...

I try to read between the lines: are you trying to get those events in your QGraphicsItems or in your QGraphicsScene? If so, you need to use QGraphicsItem::setAcceptTouchEvents on your items, then you get the QTouchEvents in your QGraphicsItem::sceneEvent() override (or QGraphicsScene::event).

I got it to work! I was reusing the code I wrote for the SOAP service so I had: @ manager->post(request, "") @ I changed it to @ manager->get(request) @ and that did the trick. (Also, apparently the url parameters are case sensitive, though that wasn't the original issue.) EDIT: And of course, thanks to everyone!

Here is it: @void Sprite::putPixel(QImage &image, int x, int y, uchar red, uchar green, uchar blue, uchar alpha) { if (image.isNull() || !image.valid(x, y)) return; int n_channels = image.depth() / 8; Q_ASSERT_X(n_channels == 4, "Sprite::putPixel", "Invalid image channels"); Q_ASSERT_X(x >= 0 && x < image.width(), "Sprite::putPixel", "index out of range"); Q_ASSERT_X(y >= 0 && y < image.width(), "Sprite::putPixel", "index out of range"); image.setPixel(x, y, qRgba(int(red), int(green), int(blue), int(alpha))); }@ Or do you mean something else?

_Mann, did you actually manage to get Lion to build a debug version of your code which you can actually debug using Xcode's gdb? (Sorry, that I am not able to help you with your actual problem though!)

Oh that's good point, Slots/Signals mechanism is really flexible. It will save us lot of time. Thanks for your help

If there is no separate package, I would say: no. But that's getting kind of out of scope for this forum now. To get a definitive answer I would better ask in a Debian forum. I personally have only an older version of Kubuntu running.

Hi quizzical, Am I right, you try to get the widget pointer of the other running application? That is not possible! You can set an activationWindow for the local application / process. and it only works inside this process. This sendMessage send a message to the first instance of the QtSingleApplication which resides in a different process. You will not get pointers of that process.

Thank you very much for your answers guys. I had briefly thought of scope but thought I would have gotten an error when the Scene realised that it couldn't see an object it was supposed to have owned.. and of course all my debugging was in the same scope (duh :) ) For anyone else starting out like me and reading this, this link was quite useful in explaining the scope of the stack and heap. http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap Thanks also for the tip about using the parent to clean up too, ZapB.