stuck with the example "CS001617 - Receiving an SMS in Qt"

[wujienokia]

The example is given at http://wiki.forum.nokia.com/index.ph...g_an_SMS_in_Qt

What I did on Windows 7:

1. Used Qt-Creator of the Nokia Qt SDK-1.0 to create a Mobile Qt Application
2. merged the example code snippets into mainwindow.h/.cpp
3. made necessary changes in the .pro file
4. target was set to Qt MinGW 4.4 Simulator

Problem 1:

Comilation was mostly alright. One exception:

#if defined(Q_WS_S60)
w.showMaximized();

didn't seem to take effect unless I explicitly #define Q_WS_S60. Is this the supposed behavior? Do we always have to explicitly do that to make the 2 statements effective?

Problem 2:

Even when the 2 statements above take effect, in simulation, the application main window is squashed into the upper-left corner of the simulaor screen, no matter which one of the Symbian Touch/NonTouch, Symbian^3, Maemo is chosen, why?

Problem 3:

The most serious problem is that, the application always crashes at the statement

QMessageBox::information(this, "Incoming SMS", messageString);

in the slot function processIncomingSMS() when an "Incoming SMS" is triggered in the simulator control panel. At this time, the QMessageBox containing messageString (the sms message body) does show up but again is squashed into the upper-left corner. Moreover, error messages are shown in the "Application Output" panel of Qt-Creator:

Messaging : Added storage configuration for account 17
Messaging : Added storage configuration for account 18
Messaging : Migrated content data for account 17 to version 101
Messaging : Migrated content data for account 18 to version 101
ASSERT failure in QWidget::mapTo(QWidget *parent, const QPoint &pos): "parent must be in parent hierarchy", file kernel\qwidget.cpp, line 4078
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.

Also at the system level, an error window popped up with the follwing error message in it:

This application has requested the Runtime to terminate it in an unusual way.
Pleace contact the application's support team for more information.

The form of the application remains the default size given by the Qt-Creator wizard. I did add a couple of label/button controls on the form, but this had no effect on the critical error. It seems to be related to the hierarchy of the QWidgets, but I have no more clues.

I am pretty new with qt-mobility, so any hints are highly appreciated!

[divanov]

Q_WS_S60 didn't seem to take effect unless I explicitly #define Q_WS_S60. Is this the supposed behavior? Do we always have to explicitly do that to make the 2 statements effective?

Naturally Q_WS_S60 is not set for emulator as emulator is not Symbian OS.

Even when the 2 statements above take effect, in simulation, the application main window is squashed into the upper-left corner of the simulaor screen, no matter which one of the Symbian Touch/NonTouch, Symbian^3, Maemo is chosen, why?

Make sure you do not call QWidget::resize() anywhere.

The most serious problem is that, the application always crashes at the statement
QMessageBox::information(this, "Incoming SMS", messageString);

in the slot function processIncomingSMS() when an "Incoming SMS" is triggered in the simulator control panel. At this time, the QMessageBox containing messageString (the sms message body) does show up but again is squashed into the upper-left corner. Moreover, error messages are shown in the "Application Output" panel of Qt-Creator:

Could be messageString is a wild pointer? Are you sure that "this" points to child of QWidget?

[wujienokia]

Naturally Q_WS_S60 is not set for emulator as emulator is not Symbian OS.

Make sure you do not call QWidget::resize() anywhere.

Could be messageString is a wild pointer? Are you sure that "this" points to child of QWidget?

Thank you, Divanov! I did find that the Mobile Qt Application wizard created such a statement for UI:
MainWindow->resize(800, 480);
After I comment it out, everything works well. Even the old Problem 3 dissapears. If I change it to resize(0, 0); program works well too. Thus it looks like a problem due to a size specified larger than what the screen supports... Well, I haven't tried other sizes to resize yet.

However, a new problem emerges. If I trigger the "Incoming SMS" a number of times, twice or triple would do, the program crashes again after some waiting time with the following error messages:

Messaging : Added storage configuration for account 49
Messaging : Added storage configuration for account 50
Messaging : Migrated content data for account 49 to version 101
Messaging : Migrated content data for account 50 to version 101
Waiting for RPC reply to 'paintWidget'' call timed out
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.

It seems to be sth. wrong related to the simulator itself instead of the test application?

[divanov]

It's hard to say as I don't use simulator.

[wujienokia]

I moved to test on device (Nokia 5230 running S60v5 with Qt/Qt-Mobility/App TRK installed through the Nokia Qt SDK 1.0). I allow All software to be installed in the program management settings. So the requirement of capabilities specified on http://wiki.forum.nokia.com/index.ph...g_an_SMS_in_Qt should not matter at this stage. I got the following unsolved error and I am still working on this famous "General OS-related error".

Executable file: 12269 2010-09-02T20:18:26 C:\programs\NokiaQtSDK\Symbian\SDK\epoc32\release\gcce\udeb\TestSmsInterception.exe
Package: 12156 2010-09-02T21:52:12 C:\workspace\symbian\qt\TestSmsInterception\TestSmsInterception.sis
Deploying application to 'Nokia 5230 USB (COM17)'...
Copying installation file...
Installing application...
Could not install from package C:\Data\TestSmsInterception.sis on device: General OS-related error
Finished.

Btw, I was often amazed at the obscure error information generated by the Symbian C++ development environment. I suppose being a little bit more specific on cause of the errors could have made it much more developer-friendly... or symbian-noob-friendly... For example, there does not even exist the directory C:\Data at all!

[james1980]

I moved to test on device (Nokia 5230 running S60v5 with Qt/Qt-Mobility/App TRK installed through the Nokia Qt SDK 1.0). I allow All software to be installed in the program management settings. So the requirement of capabilities specified on http://wiki.forum.nokia.com/index.ph...g_an_SMS_in_Qt should not matter at this stage. I got the following unsolved error and I am still working on this famous "General OS-related error".

Executable file: 12269 2010-09-02T20:18:26 C:\programs\NokiaQtSDK\Symbian\SDK\epoc32\release\gcce\udeb\TestSmsInterception.exe
Package: 12156 2010-09-02T21:52:12 C:\workspace\symbian\qt\TestSmsInterception\TestSmsInterception.sis
Deploying application to 'Nokia 5230 USB (COM17)'...
Copying installation file...
Installing application...
Could not install from package C:\Data\TestSmsInterception.sis on device: General OS-related error
Finished.

Btw, I was often amazed at the obscure error information generated by the Symbian C++ development environment. I suppose being a little bit more specific on cause of the errors could have made it much more developer-friendly... or symbian-noob-friendly... For example, there does not even exist the directory C:\Data at all!

Hi,

It was shown that .sis file had been generated and error occured while SDK is trying to installed it. So the problem is of the capability is there. And the SDK is first copy the .sis file to your device and than try to install it into the device. Find the location where it is store on your device and try to install it from there it will give you the error
" Required appplication access not granted "

[gaba88]

yes correct the problem is with capabilities, you can try with building the application in release mode and then sign the application using your own dev cert if you have or sign that using symbian open sign, then i guess that will work for you.

[wujienokia]

You are right, james1980 and gaba88! Thank you. That means, even if I configure the device to allow All software to be installed, in effect, the phone OS still verifies the capabilities of the softpack before it lets the installation go on. Quite different from the way of Windows Administrator and Linux root, but interesting indeed...