札记

 第一部分消息

<EVENT id="EVT_ID_SRV_ALM_OP" type="SENDER"/>
这里一定是发送者的res文件里面写上的，原因是会产生一些c语言的头文件，里面对id做定义

<RECIEVER id="EVT_ID_SRV_REMINDER_PWRRESET_REQ" proc="vapp_alarm_evt_handlr"/>
这里是在接收者的res文件里面写好，作用就是把这个函数和这个evt绑定起来，有这个evt发出来，这个函数就会被call到

按照你提供的资料。我看了下代码，总结了下面几点：
在app的.res文件里面有 <EVENT id="EVT_ID_SRV_ALM_OP" type="SENDER"/>的话会有以下修改：
1、在对应得mmi_rp_xx_def.h文件里面生成了对应的EVENT_ID
2、在Mmi_rp_callback_mgr_config.h文件中有一对宏：
MMI_FRM_CB_REG_BEGIN(EVT_ID_SRV_ALM_OP)
MMI_FRM_CB_REG_END(EVT_ID_SRV_ALM_OP)
3、如果在.res中也存在对应的 <RECIEVERid="EVT_ID_SRV_ALM_OP"proc="vapp_alarm_evt_handlr"/>
会在上面的一对宏之间生成宏MMI_FRM_CB_REG(vapp_alarm_evt_handlr)
请问以上几点有没有错误?
另外还想问一下:
1、代码中使用mmi_frm_cb_reg_event函数来注册和在.res中使用<RECIEVERid="XX"proc="xx"/>
的效果是不是一样的？
2、我在某个.res中使用<EVENT id = xx>来生成了事件ID，在另一个.res文件中直接使用这个ID不需要包含相关的头文件吗？

没有错误
另外还想问一下:
1、代码中使用mmi_frm_cb_reg_event函数来注册和在.res中使用<RECIEVERid="XX"proc="xx"/>
的效果是不是一样的？

mmi_frm_cb_reg_event这个是动态注册，有一个mmi_frm_cb_dereg_event配合使用，达到省memory的目的（这个目的也不一定能成立，因为要多写code）
2、我在某个.res中使用<EVENT id = xx>来生成了事件ID，在另一个.res文件中直接使用这个ID不需要包含相关的头文件吗？
不用包含，因为sender里面有写头文件，会自动产生include之类的代码

 

第二部分一些UI函数

我看到VfxTextFrame类有两个API：setAutoResized和setFullLineHeightMode可否详细介绍下这两个API分别应用在什么场合？ 谢谢~

setAutoResized这个API是指自动缩放frame到字串大小。当你设置frame是50*50的，但是里面的字符串是20*20的，那么设置之后text frame的大小是20*20。

setFullLineHeightMode这个API是指按照所有语言的最大高度计算行高。当你设置text frame的时候，如果是多行的，要计算每一行多高。此时如果用当前语言的值计算，就会出现两种语言混排的时候比较高的那个被截断。或者是先放入a，之后放入“中”，中比较高，看上去a就会往上跳一下。所有对于混排的时候，需要注意这个函数。

 

第三部分资源

我看到service的文件是在plutommi\Service\这个目录下的，它们的资源ID分配也和09b35之前的版本是一样的是在Mmi_res_range_def.h中。
而cosmos的app则添加在\venusmmi\app\Cosmos\下面，资源ID分配则通过在vapp_package_res.h中。

针对此我有几个问题想咨询下：
1、资源ID在Mmi_res_range_def.h和vapp_package_res.h中分配有何区别？ 我能不能将service的ID分配由Mmi_res_range_def.h转移到vapp_package_res.h?
2、我现在在添加一个cosmos的应用，应用的文件是添加在cosmos.mak中的, 请问除了添加在这里之外还有没有别的方式(比如可以自己建个.mak什么的)？ 另外我看到还有cosmos.lis,cosmos.pth和cosmos.inc请问这几个文件是为了兼容MMI_VERSION==PLUTO_MMI的情况吗？如果我是MMI_VERSION==COSMOS_MMI是不是可以不用去管？

在mmi_res_range_def.h会include vapp_res.h,而vapp_res.h会将vapp_package_res.h include进去，在
下resgen动作后，resgen工具会将mmi_res_range_def.h里包含的路径下的所有res文件放到一个临时folder下，
自然定义在vapp_package_res.h的路径也会被检索到，相应folder下的res文件也会被copy到临时folder下，
接着resgen parse将这些res文件parse出来，生成相应的资源。
因而，资源id放在这两只文件中没有什么区别，只是对于一些比较common的会放到前面的那支文件中，而对于
commos用的放在后面这支了

将app的.c和.h路径添加在cosmos_app.mak中主要是为了好管理，当然也可以独立出来另外起一个mak.这个需要改动到option.mak比较复杂，不建议在这上花费太多时间
cosmos.lis,cosmos.pth和cosmos.inc这几支文件是透过.mak文件解析出来的，在mtk1108版本之前，需要手工来创建
这几支文件，现在只要在.mak统一加上SRC_LIST、INC_DIR、COMP_DEFS、SRC_PATH，由mtk的脚本自动帮我们完成这些工作。

第四部分VCUI

APP创建CUI，CUI通过event将Result传递给APP，APP会接受到这些Event，并进行处理。
一般情况，Event会发送到VfxApp的onProc里面，所以App需要继承onProc.
如果调用了vfxSetCuiCallerScr，Event就会发送给VfxScreen，只需在Page层继承onProc即可。

 

第V部分VcpBaseListMenu::updateAllItems() VcpBaseListMenu::resetAllItems()

我看到VcpBaseListMenu类有两个函数updateAllItems()和resetAllItems(VfxBool )请问它们效果上有什么区别，分别适用在哪些场合？比如我改变了menulist的个数或者内容应该用哪一个合适？

resetAllItems会将所有的list menu cell先close掉，然后重新create，因此刷新的效益上会慢，但如果显式区中cell个数有更改时，这个API就可以将新增加的cell显示出来，所以这个经常使用的场景是有增减cell，或者是修改了cell的内容导致原本只可以显示6个的部分，在修改后可以显示7个出来，这部分都可以用resetAllItems来更新

updateAllItems只是对已有的cell内容做update，不会去create以及close cell，因此比较适合于某些list menu只是显示的内容有更改，而整个cell个数没有更改的情况

 第VI部分 NVRAM恢复出厂设置

若添加NVRAM项当具有NVRAM_ATTR_FACTORY_RESET属性时，就会在恢复出厂设置是恢复为DEFAULT值.
若添加NVRAM项到common_mmi_cache_byte[]，则将其RESTORE_FLAG设为KAL_TRUE,则会在恢复出厂设置时恢复为设定的默认值。

 

 第VII部分 menu类型

menu type的类型有APP_MAIN 、APP_SUB、OPITON等。有几个问题想请教下：
1、 这几种类型有什么区别？ 分别应用在哪些场合？
//mtk add
APP_MAIN和APP_SUB这两个从目前的情况来看没有区别

option是指在点击某个menu item时，会在旁边popup一屏的菜单供选择

type="SEPARATOR" means that CUI will show a separator here

 

 

待续~