×

Discussion Board

Results 1 to 4 of 4
  1. #1
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    55

    Recv() doesn't post status messages..?

    Hi all,
    I've got this code that does not seem to be behaving as the API says it should, though I've modelled after the ECHO example. Here it is in part:

    class TVNetReader : public CTimer {
    ...
    }

    void TVNetReader::ReadNextData() {
    //Allocate buffer, then...
    if (!IsActive()) {
    printf ("ST2\n");
    printf ("ST2\n");
    iSocket.Recv(*bufPtr, 0, iStatus);
    SetActive ();
    }
    }

    void TVNetReader::RunL()
    {
    printf ("ST1: TVNetReader RunL\n");
    if (iStatus != KErrNone) {
    //Handle error
    return;
    }
    //else process the received data.
    }

    I've placed the printf statement there for debugging, and it never gets displayed. The RunL() function is never called for some reason, even after a significant delay of a few minutes.

    On the other hand, I DID have some working code as follows:

    void TVNetReader::ReadNextData() {
    //Allocate buffer, then...
    iSocket.Recv(*bufPtr, 0, iStat);
    User::WaitForRequest (iStat);
    if (iStat != KErrNone) {
    //handle error.
    } else {
    //Process data.
    }
    }

    This version, which uses WaitForRequest(), works like a charm. However since it is handled serially and introduces an unacceptable delay in the code, it is necessary that I be able to use the signalling mechanism so that other functions can be called while I am downloading data.

    Any help is greatly appreciated. Thanks!

    Gregory

  2. #2
    Super Contributor
    Join Date
    Mar 2003
    Location
    Beijing
    Posts
    3,609
    It is a little strange to me for your two piece of code. First of all, are you using CActive class in your design? If yes, you have to use "iStatus" which is a member of CActive class.

    For your information, if you use RSocket.Recv(TDes8& aDesc,TUint flags,TRequestStatus& aStatus), only the descriptor is fully filled, then your RunL will get run. If you want to get your RunL() to run whenever there is a byte coming in, you may use the following API:

    void RecvOneOrMore(TDes8& aDesc,TUint flags,TRequestStatus& aStatus,TSockXfrLength& aLen);

    Hope this helps!

    Liuxg
    Forum Nokia

  3. #3
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    55

    Some more info

    Thanks for your reply Liuxg.

    To clarify, in the first version, I'm using a class inherited from the CTimer class, which according to the API inherits from CActive. I did try inheriting from CActive as well before, with the same non-responsive results. In the course of testing out some other ideas, I switched it to CTimer instead. I am also using iStatus, in the first piece of code. The second one works fine whether I use iStatus or my own local function variable iStat.

    I do know that RunL only gets called when the descriptor gets filled, but I do not receive any response even after many minutes of waiting. And I know that the data should have been received sooner, based on the experience with the second version of the code, which I had working before. That one uses User::WaitForRequest and works quite fine.

    So what I've got is the second code that does receive data and handles it properly, but effectively suspends the entire program when User::WaitForRequest is called while it waits for the descriptor to be filled and Recv() to return. And then there is the first code that doesn't seem to receive any data at all, or at least RunL is never called even after enough time has passed to fill the descriptor completely.

    Do you or anyone else have a piece of code that does work using Recv() and not RecvOneOrMore()? Most of the API documentation uses RecvOneOrMore() as an example, and I'd like to see a code in action that works using Recv(). I've already tried using the Echo example as a model, but that doesn't seem to be working, so another example would be quite helpful.


    Thanks a lot.

    Gregory

  4. #4
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    55

    Problem solved

    I managed to figure out what happened. Basically I had a different conception of the callback framework in Symbian. After some restructuring, I got it to work. Thanks!

    Gregory

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×