TAPI 2 : TSPI_lineGetCallInfo - callerID



  • Ich dreh gleich durch. win2k svchost.exe stürtzt nach dem Aufruf von TSPI_lineGetCallInfo ab und Win98 liefert Teile der Rufnummer falsch an den TAPI-Client. Mein trace-Client zeigt mir 0x3F an den esten 8 Stellen meines
    callerIDOffset und an den ersten 6 Stellen des callerIDNameOffest.

    Sieht einer von Euch meinen Fehler?

    if(m_pLine->GetActiveCall()->IsIncoming)
        {
            pli->dwOrigin               = LINECALLORIGIN_INBOUND;
            Trace("Incoming Call");
            pli->dwCountryCode       = 49;
    
            pli->dwNeededSize+=31;
            if(pli->dwTotalSize<pli->dwNeededSize)
            {
                Trace("--Exit Structure to small");
                return EPILOG(LINEERR_STRUCTURETOOSMALL);
            }
            pli->dwUsedSize=pli->dwNeededSize;
    
            pli->dwCallerIDFlags= LINECALLPARTYID_NAME | LINECALLPARTYID_ADDRESS;        
            pli->dwCallerIDSize=18;
            pli->dwCallerIDOffset=sizeof(LINECALLINFO);
            pli->dwCallerIDNameSize=13;
            pli->dwCallerIDNameOffset=sizeof(LINECALLINFO)+18;
    
            strcpy((char *)pli+pli->dwCallerIDOffset,"+49 (0815) 4711\x0D\x0A");
            strcpy((char *)pli+pli->dwCallerIDNameOffset,"Marc Frank\x0D\x0A");
        }
    

    Bin für jede Hilfe dankbar.



  • Problem gelöst! Das Zauberwort heißt unicode. Manchmal hilft auch die MSDN-Newsgroup (sogar ein Mitarbeiter von MS).



  • Hi Mark,

    A few comments:

    1. Service providers should use unicode strings unless the documentation
      explicitly states otherwise.
    2. LINEERR_STRUCTURETOOSMALL generally implies that the buffer provided by
      the app is <= the fixed size of a structure at a specific version level, and
      TAPI guarantees that the buffers received by the SP will always be at least
      the size of the fixed structure for the negotiated version. So, it's ok for
      the SP to fill in as much info as it can, set dwNeededSize apprpriately, &
      return success. (The app might not care about the var-length fields;
      otherwise it'll see dwNeededSized, realloc a bigger buf, and retry)
    3. If your SP is negotiating an SPI ver different than that of
      TAPI_CURRENT_VERSION in TAPI.H, make sure you redefine that symbolic
      constant appropriately before #include'ing tapi.h/tspi.h, otherwise
      structure sizes will be inconsistent (compiled vs. runtime per negotiated
      ver).

    That's all i can think of without seeing a stack trace. Regards, Dan
    Knudson [Microsoft]



  • toll (dickes Lob) - Du hast die MS-Newsgroup gefunden.



  • microsoft.public.win32.programmer.tapi 🙂


Log in to reply