Qt for Symbian – odd network sockets behavior

qtqt4symbian

I grabbed the 4.6.0 release, and immediately tried writing a little test app for it. This application simply shows an edit box for a host address, and a checkbox if it's to use an encrypted connection or not. There are also simple 'Connect' and 'Disconnect' buttons. It tries to download and show an image in a QListWidget, showing debug lines along the way (connected, encrypted, readyRead, etc)

This is (somewhat obviously) using the QSslSocket class.

1) The app never prompts for an access point like most other network apps do, it simply opens the WLAN connection if it's down. How do I kick off the access point selection UI? (Or properly skip it if the user has selected auto-selection of access points… which I haven't)

2) Next, the app does not function outside my local WLAN. It sits there waiting just as it did on my WLAN before I added the "NetworkServices" capability. It stops in host lookup state if I give it a name, or if I give it an IP address it goes through to state 2 (waiting for connection state I think?) … Is there an additional capability or something I need to add here? (see update below)

3) How do I get error codes or exceptions for missing capability issues?

It took me a long while to figure out that you have to add "TARGET.CAPABILITY += NetworkServices" to the .pro file to enable network connectivity. I eventually found the place to edit it in the Carbide file, but it was autogenerated and kept getting overwritten. It then took me over an hour to figure out the capability settings for Qt are in the .pro file, not hidden in some other Carbide menu.

It'd be very useful if the Qt docs had a page listing which Symbian capabilities were required for which Qt classes/members. It'd drastically ease the amount of effort required for total Symbian-newbies like myself.

UPDATE

Okay, so now I know how to check the log file for missing capabilities in the emulator. Thanks!

I'm starting to think the 3G issue is not about capabilities at all… it's worked consistently since I started doing a clean before each build. I was getting app crashes and even corrupted Qt networking stacks (where it took a phone restart to get connections working again, but only within Qt-based apps), etc… If it can't do a partial build correctly, there's no telling what it's actually putting in there.

Is there any known issue with Carbide's build vs. clean-then-build? Maybe it's a Qt for Symbian problem? Perhaps I need to start a fresh VM and reinstall everything. (For the third time in a week… First was the release candidate)

Best Answer

I don't have the answer for your other questions, but I am looking into Qt as well.

About checking capabilities, the emulator does do that. When it stumbles across a missing capability it logs something like "PlatSec fail for proces..." in EPOCWIND.OUT in your temp directory. You can also enforce it so the app won't even run by editing epoc.ini.

Related Topic