Win 程序员如何过度到Symbian程序员？

　　6.应用框架。

　　Symbian操作系统的确提供了一套用以建立应用程序的类，然而同时，使之能够建立基于非对话框的应用程序界面的框架代码却非常少。要处理像焦点转移这种事件只有靠手工。这个例子当然很容易理解怎样来做，但实际上每个屏幕画面被设计的时候都要仔细考虑它们可是一件费时费力又容易招致错误的事情。从Symbian操作系统6.1版开始，Symbian操作系统增加了一个很简单的机制使用惟一的ID号来实现不同屏幕之间的切换，但是要做的事情还很多。

　　这里有一个适用于大多数初级情况的例子：这里没有使用API来给屏幕增加一个控制，而是使用了视图对象中叫做CountComponentControls和ComponentControl的两个对象，后者必须为从0到前者返回值之间的每个整数给UI控制返回一个指针。要添加一个控制，除了构造，调整大小，在恰当地点激活，你必须在代码里对CountComponentControls的返回值进行累加，还要在ComponentControl函数中给switch语句添加一个case. Symbian操作系统确实提供了根据资源文件建立对话框的完美合理的途径。当你在资源文件里声明对话框时，你不必直接对这些东西寻址。但是由于对话框只允许在一个竖列中布置控制，对于一些高级的应用程序中复杂的屏幕设置来说可能并不适合。

　　7.窗口问题。

　　Symbian操作系统不鼓励使用“自有窗口”控制。这就是说，一个控制并不总是持有自已的窗口（从受按Z轴顺序裁剪的窗口系统控制的图形对象意义上来说）。因为这些对象使用了系统资源，应用程序应该简单的执行一个合适的绘画功能来规定它所在矩形的边界。这对于习惯每个控制有一个真正窗口的开发者来说可能感觉不同，但是掌握这一点并不困难。

　　虽然Symbian操作系统的标准UI控制集十分丰富而且强壮，但是偶尔也会有误操作的情况发生。比如我们已经有了一个带滚动条的编辑框，现在要能够暂时用另外一个控制取代它。仅仅使编辑框不可见并不能解决问题。编辑框的某些内容，包括滚动条，仍然以多种有趣但不可接受的方式存在着。我们认为这可能应该归咎于前面提到的编辑框的复杂的对象结构；看起来在这种分布式结构中要想进行隐藏可不是无关紧要的问题。我们最后是通过在画面以外重新定位它解决的。