Hi

One reason can be the touch setup
-- Can you please explain a little more on this?
Well since it only happens sometimes, i guess its not that.
I have seen something like it when touch was setup for gestures and you kinda moved the finger
when you "clicked" it would then start the gesture and sort of eat the click.

Could also be a bug in Qt4.8 that the later fixed with Grabmouse
-- Is there any defect ID that you remember? That will add more waitage for the understanding.
Sorry nope. it was a duck. It was due to calling a message box that would run event loop and
button would not redraw before after.

One of the other thought that I have is, if this is really a UI issue or this is being a side effect due to any other -problems such as CPU load, Memory full, etc. Do you think it is possible?

Yes that is really possible if the target is low powered board and it's low on say ram then the same task might
suddenly take much longer and the button will appear down.

Have you tested with a button that does nothing and see if that can get stuck?

Hi @Paul-Colby,

Awesome!
Now, I understand better what the Qt document wanted to say about this function.
(Probably, an example in the doc would be useful.)

It's a different question, but is there any way to move the xmlns attribute outside from this tag?
(Example, If I would use more <fooelement> tags, it would be redundant to see this definition again.)

Thanks a lot!

I'd say: benchmark it, so you'll know how much time it takes to do the match. Don't forget to load several dictionaries to match real-life setup

But this time, I have a different error:

/home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: /home/kumararajas/Integrate_UI/G-CPU/lib/libuicorelib.a(uicontroller.o): undefined reference to symbol '__cxa_begin_catch@@CXXABI_1.3' /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: note: '__cxa_begin_catch@@CXXABI_1.3' is defined in DSO /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../arm-linux-gnueabihf/libc/lib/arm-linux-gnueabihf/libstdc++.so.6 so try adding it to the linker command line /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../arm-linux-gnueabihf/libc/lib/arm-linux-gnueabihf/libstdc++.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[4]: *** [bin/FireApp] Error 1 make[3]: *** [libraries] Error 2 make[2]: *** [libraries] Error 2 make[1]: *** [libraries] Error 2

This looks like standard library compatibility issue.

Any thoughts on this?

Well, during development, it will show error in "Application Output" but so far I did not find a good solution to check when deployed.

It might be a good idea in final release to embed the file in qrc so it cannot be corrupted if that is an option.

Alternative, you could have a hidden object
and in the end of the stylesheet, alter some values for that widget
that you can also access from code. That way you can check if it was applied.

@Chris-Kawa said:

Chris, I completely agree with you and it makes sense to me.
The whole build be called out for a version and that should be managed at testing level. Not by versioning through comments, which doesnt makes sense.

Thanks a lot for taking much time in making me clear.

On the fly just got a thought in my mind on versioning the Makefile. qmake generates make fine with the below header:

############################################################################# # Makefile for building: bin/blah # Generated by qmake (2.01a) (Qt 4.8.4) on: Fri Jul 31 16:22:38 2015 # Project: blah.pro # Template: app # Command: /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/qmake -o Makefile blah.pro #############################################################################

I do see the version of qmake

qmake (2.01a) (Qt 4.8.4)

Incompatible qmake can cause a problem. So the qmake is being bundled with the Qt version as a whole build.

Hopefully, I am OK with the understanding. Please let me know if you have any more thoughts on this.

Thank you!

Cheers,
Kumara

This is a quite old topic but what is the current situation for this problem?

Just checked the code of FlickCharm, it does not touch the paintEvent so it looks like what you want, no ?

It's not the default. However, that option doesn't disable a module, it disable the use of OpenGL globally. You have to rebuild Qt.

@SGaist I tried with Qt 4.8.6, same problem. :(

Hi,

Isn't this a duplicate of this thread ?