PB对DW数据窗口操作必学

/*******DataWindow Object 的几个有用的属性*********

/*

dw_1.Object.DataWindow.Column.Count属性记录的是 DataWindow 中的列数。 

  DataWindow中的所有对象都有 Type 属性，通过访问他们的 Type 属性可以得知他们是 Column、Compute、Text等等对象。

动态改变 DataWindow 某一列的 Edit Style ： 

      将某一列的原来的 Edit 风格变成DropDownListBox  

        dw_1.modify("column1.ddlb.useasborder=yes") 

    如果还想做其他的修改，请参考本站点中的文章。  

DataWindow 控件中的 DWObject参数想必这一定是一个非常热的话题！

    在 DataWindow 控件中有许多事件的参数都是 DWO。DWO 全称DataWindowObject 。它指的是 DataWindow 中的一个对象。例如一个计算列、Text 框、Picture Box等等  

    对象，或者是 DataWindow 本身。通过访问 DWO我们就可以知道当前用户触 

发的是哪个对象。例如：  

       

    Dwo.Name = "datawindow" //说明此时 DWO 代表 DatawindowObject 本身。  

    Dwo.band = "header"     //说明该 dwo 位于 header 区。  

    关于 Dwo 的其他属性应该如何访问，与访问 Datawindow属性一样，具体方 

法到本站找！

DataWindow 内部函数 

    DataWindow 有许多内部函数（只能在 DataWindow 画笔中使用），它们都不能从PowerScript中直接调用。不过我们可以利用 DataWindow Control 的函数 Describe 与DataWindow 的 Evalute 结合起来运行。例如 DataWindow 的内部函数 LookupDisplay (Column ) 则是获取某一列上的显示值的函数。它与 Powerscript 中的 GetItem 函数不一样，GetItem函数获取的是数据值。

例：dw_1.Describe ("Evaluate('LookupDisplay(produceid)', 1)" ) 

    获取 productid 列的第一行记录当前的显示值。 

    DataWindow中都有那些内部函数，以及各个内部函数的使用与用意的资料我们目前都没有找到。我们也只是一点一点的积累，如果有那位朋友知道的话，可千万要拿出来与大家分享哦！！！

Browse 的使用  

    Browse 是 PB 开发环境中的一个画笔，与Library、Database、DataWindow 一样。但是却很少有人提到过它。Browse其实是一个非常有用的工具。有人抱怨知道如何更改 DataWindow Object 属性，但是又不知道究竟有哪些可以修改。使用Browse 就简单了。Browse 中的 Tab 控件上的 DataWindow 页列出了当前应用程序所有的的 DataWindowObject 。同时窗口的右边列出了 DataWindow Object 具备的所有属性。右击一个属性，选择Copy 。此时 PB就将访问该属性的脚本格式 Copy 到粘贴板上去了。你只需在你的源代码中 Paste 即可。Browse还有许多其他用途。Browse 可以以树状的形式将你应用程序中的所有的 UserObject 或着 Window 之间的继承关系全部显示出来。对于PFC 的初学者将是受益非浅，它可以帮你把 PFC 所有对象之间的继承关系清清楚楚的现实出来。Browse 中的OLE页中也非常有用，它将你机器中的所有OLE对象、ActiveX对象、COM对象都清清楚楚的列出来。如果你想知道你的机器中有哪些组件可以使用用它可以轻松找到。关于Browse的具体使用说明本人也从没见过，我想可能是大家都觉得没什么可讲的吧。其实想想也是，所有操作只需点右健，当然没什么可以多说了！顺便问一句PB 是不是很强大？

PB 的怪现象  

    有许多 PB 开发人员都抱怨 PB 总是无缘无故的出现一些怪毛病。那么我告诉大家一套规则： 

    “如果你一大早来到 PB 面前，发现程序无缘无故出了 Bug。但是又死活想不出毛病在哪（昨晚还是好的，今早就坏了）。立即将你的应用程序的所有对象都重新生成一边（在 Library 画笔中使用Regenerate），最好是按继承顺序 Regenerate 一边。说不定 Bug 就消失了”。 

    不要觉得这条规则好简单，说不定这条归则就可以帮你节省大量的时间。你们有没有想过Powersoft 公司为什么要在 PB 中提供一个 Regenerate功能。我觉得它就是为了应付这种毛病。因为，除了这种情况下，我再也想不出使用 Regenerate 的理由。

PB 开发 COM 存在的问题 

    安装了 PB gernerate 的朋友可以使用 PB 开发 COM组件，但是目前还只能开发进程中 COM 。PB 开发 COM 有几个问题需要注意一下。 

    1. 使用 PB 的 Project 画笔编译好了 COM 组件后还不能使用，还要将对应的PBL 编译成 PBD 或则 DLL，具体是 PBD 还是 DLL 要看在编译 COM 时如何设定的。一般默认情况是 PBD。编译好了 PBD 或 DLL后，才能正常使用 COM 组件。当然使用前 COM组件还应注册。如果你要发行你的 COM 组件，还必须要PB 的 DDDK 中的 DLL，就发行应用程序一样，还需要 PB 的 DLL 支持。 

    2. 不支持函数覆盖（OverWrite）  

    PB 制作 COM 时是将不可视用户自定义对象（不妨命名为 n_cst_o b j e ct）编译成 COM 组件的接口。它将 n_cst_o b j e c t 所有共有属性、函数、事件都编译成 COM组件的一个结构。但是如果这个n_cst_o b j e c t 还有一个父类，并且 n_cst_o b j e ct还覆盖了父类中的函数，那么此时编译 COM 操作将无法通过。原因是 PB 在制作 COM 组件时会将 n_cst_o b j e ct 的父类中的所有属性、函数、事件也编译进去。所以，此时 PB发现两个一模一样的函数，编译也自然通不过了。解决办法很简单，将原来需要覆盖的函数申明成保护类型。这样函数就可以最随意覆盖了。但是申明成保护类型后外界也就无法访问该函数了。那么我们再在n_cst_o b j e ct的父类中申明一个共有类型的函数，该函数只是简简单单的调用原来南各函数。至此一切问题都解决，函数可以覆盖了。下面是关于这个问题的伪代码。 

问题代码：  

    Class n_cst_parent  

    {  

    public :   

      int a() { //do something }       

      int b() {//hello! }     

    };  

    class n_cst_o b j e c t : n_cst_parent 

    {  

    Public :      

      int a() {//OverWrite Parentscript }  

    }  

此时将 n_cst_o b j e c t 编译成 COM组件的接口，那么这个接口具备的函数将会是 

      int a()   //来自n_cst_parent  

      int b()   //来自n_cst_parent  

      int a()   //来自 n_cst_o b j e c t  

显然这种 COM接口不可能出现，因此编译失败了。将上面的问题代码改为如下形式：  

Class n_cst_parent 

{   

  protected: 

    visual int a1() {//完成原来 n_cst_parent.a() 要完成的工作 } 

  public: 

    int a() { return a1(); }  

    int b (){ //hello }  

}  

Class n_cst_o b j e c t :n_cst_parent  

{  

  protected: 

    int a1() {//完成原来 n_cst_o b j e c t.a() 要完成的工作 } 

}  

此时再将 n_cst_o b j e c t 编译成 COM的接口，那么这个接口具备的函数将会是  

      int a()   //来自n_cst_parent  

      int b()   //来自n_cst_parent  

而且 int a() 函数调用的将是 n_cst_o b j e c t中的 a1() 。因为 a1() 被申明成虚函数。  

所有问题全部解决！！！  

以上代码只是伪代码，PB 中的对象继承根本不是这样。还有在 PB中函数已经申明就已经是虚函数。直接具备多态特性。