Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 4 days, 5 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 5 days, 4 hrs ago - more...
|
2010-04-16
, 11:15
|
|
Posts: 34 |
Thanked: 2 times |
Joined on Feb 2010
|
#12
|
I think I had a similar situation when i used QMessageBox.
In my case, I had a QNetworkReply and on the slot received from error() signal i created a QMessageBox using the static function QMessageBox::warning.
After the messagebox show and accept, the application was crashing from time to time.
I think the static creation of QMessageBox is modal and it blocks the event loop.
I had a better behaviour when i changed the static creation of the message box with a non modal one.
On the hideEvent function you can close the dialog.
Hope this can help.
In my case, I had a QNetworkReply and on the slot received from error() signal i created a QMessageBox using the static function QMessageBox::warning.
After the messagebox show and accept, the application was crashing from time to time.
I think the static creation of QMessageBox is modal and it blocks the event loop.
I had a better behaviour when i changed the static creation of the message box with a non modal one.
Code:
QMessageBox *msgBox = new QMessageBox( this );
msgBox->setWindowTitle( tr(" HTTP Error "));
msgBox->setIcon( QMessageBox::Warning );
msgBox->setText(tr("Error during download: %1")
.arg(QString( stringError ) ));
msgBox->show();
Hope this can help.
| The Following User Says Thank You to flgor For This Useful Post: | ||
 |
|
2010-04-16
, 11:19
|
|
Posts: 1,296 |
Thanked: 1,773 times |
Joined on Aug 2009
@ Budapest, Hungary
|
#13
|
QMessageBox is not the problem.
I actually added it later in development to the code in question, and the issue was present before. And the issue persists if I comment it out.
I actually added it later in development to the code in question, and the issue was present before. And the issue persists if I comment it out.
__________________
You should follow me on Twitter!
Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish
You should follow me on Twitter!
Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish
|
|
2010-04-16
, 11:23
|
|
Posts: 34 |
Thanked: 2 times |
Joined on Feb 2010
|
#14
|
QInputDialog::getInt is the same story. These are all static functions.
|
|
2010-04-17
, 14:32
|
|
Posts: 1,296 |
Thanked: 1,773 times |
Joined on Aug 2009
@ Budapest, Hungary
|
#15
|
And what's the problem with modal dialogs?
Perhaps they are implemented poorly, and therefore cause segmenation faults?
Why doesn't the try-catch block catch it?
Perhaps they are implemented poorly, and therefore cause segmenation faults?
Why doesn't the try-catch block catch it?
__________________
You should follow me on Twitter!
Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish
You should follow me on Twitter!
Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish
|
|
2010-04-24
, 13:32
|
|
Posts: 148 |
Thanked: 199 times |
Joined on Nov 2009
|
#16
|
Qt does not use exceptions, in general.
I ran through the dialogs several times now, no crashes. However, the technical problem one could see with modal dialogs are the nested event loops they create.
If you can reproduce the crash on your box then I would recommend using native-gdb (in your sbox' x86 target), or valgrind.
Does MADDE not allow you to properly debug your application?
(Also, "bool *someVar = new bool" is not a good idea - how do you guarantee that your delete statement is ever reached? It's generally better to allocate local variables on the stack, and if a method requires a pointer you can use the address operator on your variable instead.)
I ran through the dialogs several times now, no crashes. However, the technical problem one could see with modal dialogs are the nested event loops they create.
If you can reproduce the crash on your box then I would recommend using native-gdb (in your sbox' x86 target), or valgrind.
Does MADDE not allow you to properly debug your application?
(Also, "bool *someVar = new bool" is not a good idea - how do you guarantee that your delete statement is ever reached? It's generally better to allocate local variables on the stack, and if a method requires a pointer you can use the address operator on your variable instead.)
Any new ideas on the problem?
You should follow me on Twitter!
Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish