i) presumably VS has an option to break (in the debugger) when an exception is thrown.
ii) the stacktrace will show you where the exception is thrown
iii) you have to wrap the call with a try-catch block and handle the exception appropriately
i) presumably VS has an option to break (in the debugger) when an exception is thrown.
ii) the stacktrace will show you where the exception is thrown
iii) you have to wrap the call with a try-catch block and handle the exception appropriately
try to "reimplement QApplication::notify() and catch all exceptions there.".
Qt Assistant -- rocks!
please, use tags [CODE] & [/CODE].
Hi,
Thanks for replies.
I didn't find it.i) presumably VS has an option to break (in the debugger) when an exception is thrown.
I looked it but all the calls before the crash are from "ntdll.dll" "my3rdLib.dll", "kernel32.dll", "gdi32.dll" and "user32.dll".ii) the stacktrace will show you where the exception is thrown
I think that the problem can be on the "display" process because disabling it the application don't crash(it is a multithreaded application that the main thread recieves what to display and display them).
I have tried but it is not called anytime.try to "reimplement QApplication::notify() and catch all exceptions there.".
Thanks,
Òscar Llarch i Galán
Hi,
Two questions:
1) I think that the display operation is performed by GDI(I'm using Windows). So, maybe displaying too many fast can crash the application?
2) Can a QQueue be accessed by two threads, the first one "enqueuing" and the second one "dequeuing"? As I readed in the doc the queue can be accessed at a time by two or more threads because it is thread-safe.
Thanks,
Òscar Llarch i Galán
Bookmarks