CActive类介绍

3.15.2  CActive类

一个活动对象类必须直接或间接地从定义在e32base.h里的CActive类派生而来。CActive是一个抽象类，它有两个纯虚函数--RunL()和DoCancel()。

构造

在构造时，从CActive派生的类必须调用基类的保护构造函数，并传入一个参数以设置活动对象的优先级。与线程类似，所有的活动对象都有一个用来决定它们如何被调度的优先级。就像前面的小节里讲过的一样，一旦活动对象开始处理一个事件，在事件处理函数返回到活动调度器之前，它就不能被抢占。在此期间，可能会产生一些完成事件。当活动调度器再次运行时，它必须决定接下来运行哪个活动对象。如果有高优先级的活动对象在等待，则不希望去运行低优先级的活动对象，所以处理事件的顺序是按优先级的高低而不是事件完成的先后。

在活动对象的构造函数中，活动对象也应该通过调用CActiveScheduler::Add()将自己加入活动调度器中。

发出请求并在RunL()中做完成后的处理

图3-3展示了当一个活动对象向一个异步服务提供者提交请求时的基本动作顺序。活动对象提供了公共的方法来提交这样的请求，标准的行为如下：

图3-3  一个活动对象向一个异步服务提供者提交请求时的标准行为

(1) 检查未完成的请求。

活动对象永远不能有一个以上未完成的请求，所以在试图提交一个请求前，活动对象必须检查自己是否已经在等待某个请求的结束了。

(2) 提交请求。

活动对象通过传入TRequestStatus成员变量(iStatus)来向服务提供者提交请求。在启动异步请求之前，服务提供者必须将此值设置为KRequestPending。

(3) 调用SetActive()将对象标志为"正在等待"。

一个CActive::SetActive()调用表明请求已经被提交并且现在尚未完成。不要在请求被提交前调用此方法。

每个活动对象类都必须实现从CActive基类派生来的纯虚方法RunL()。此方法会在完成事件产生后被活动调度器调用。

RunL()应该通过检查其完成代码来检测异步请求是否成功，此完成代码是存储在活动对象TRequestStatus成员(iStatus)中的一个32位整数值。不同RunL()代码的复杂度可以相差很大，但是由于RunL()不能在它运行时被其他活动对象的事件处理所抢占，所以它应该尽快完成以便别的事件可以被没有延迟地处理。

DoCancel()

活动对象必须可以取消一个未完成的异步请求。活动对象必须实现基类的纯虚函数DoCancel()，以便在异步服务提供者上调用适当的取消方法来终止一个请求。DoCancel()必须不能异常退出，也不能分配资源，同时还不能有冗长的操作，它只能简单地取消请求并做相应的清除工作。

CActive::Cancel()调用DoCancel()并等待请求已被终止的通知。在任何时候，如果需要终止一个请求，就必须调用Cancel()而不能调用DoCancel()，因为基类的方法会检查一个请求是否仍未完成，并在请求终止前进行必要的等待。

RunError()

CActive基类提供了一个虚函数RunError()，该函数会在RunL()异常退出时被活动调度器调用。如果异常退出可以处理，则应该通过重载CActive::RunError()的默认实现来处理这个异常。

析构

CActive派生类的析构函数总是需要调用Cancel()来取消任何未完成的请求。CActive基类的析构函数检查活动对象当前是否处于活动状态，如果有任何未完成的请求，也就是说Cancel()没有被调用，那么就会产生E32USER-CBASE严重错误。这样就可以捕获到所有的忘记调用Cancel()的编程错误。在验证了活动对象已经没有未完成的请求后，CActive的析构函数将活动对象从活动调度器中移除。

在销毁一个活动对象前需要取消请求之所以那么重要，是因为不这么做的话，请求会在活动对象销毁后完成。这会造成一个"丢失信号"，因为活动对象无法找到事件的处理者。这将导致一个严重错误(E32USER-CBASE 46)。

 

摘自《Symbian OS C++编程诀窍》第3章Symbian OS开发基础。