Some things to keep in mind when using a CActive derived class as a proxy

For some reasons I needed a CActive derived class as a proxy. Being more clear a CActive derived class (A) instance didn't issue the asynchronous request to the Asynchronous Service Provider (ASP) directly instead it issues an asynchronous request to another CActive derived class (B) instance which issues the asynchronous request to the ASP. For this B has to provide an asynchronous request function which takes a reference to A::iStatus as parameter.
Within that function B issues the asynchronous request to the ASP passing in its own iStatus instance. After that (and I mean after - not before) the B instance has to set A::iStatus to KRequestPending and store a pointer to A::iStatus in an own member variable (e.g. B::iCallerStatus).

The reason why I mentioned the after is in case of an exception thrown by calling ASP::AsyncRequestL() the A::iStatus whould be pending and the Active Scheduler finds an iStatus pending without having an appropriate object "SetActive()". This results in a classic stray signal panic.

When the asynchronous request is completed by the ASP - B::RunL() is called and B::iStatus can be evaluated. In this case the outstanding request of the class A instance is completed via a call to User::RequestComplete(iCallerStatus, iStatus.Int()); It is good practise to check iCallerStatus against NULL before completing.
Rightafter A::RunL() is called and A::iStatus can now be evaluated.

The details with issuing asynchronous requests are explained in several SDK documentation.