TIPTOP 4GL combobox动态下拉与级联联动开发指南

采购单上要选一笔供应商资料主档里有几千笔数据直接用静态下拉一条条翻光是找人就要半分钟遇上跨厂区的单子还得先选工厂、再选供应商、再选联系人三级筛下来静态列表根本撑不住。这类需求在做 TIPTOP 4GL 单据开发的时候几乎每张单都会碰到很多人第一反应是把选项写死在 form 里结果上线两星期主档一变代码就得跟着改一次。所谓 combobox 动态下拉本质上是把「候选清单的来源」从编译期挪到运行期列表内容由一条 SQL、一个数组或者一次界面事件实时拼出来主档改了不用重新编译程序筛选条件变了列表立刻跟着变。这套做法落地之后供应商选择从「翻几百条」变成「三秒钟点完」后端校验也能同步收紧。这篇内容适合已经能写基础 4GL 程序、正在被下拉联动折磨的中级开发者也适合刚接手单据维护、想搞清楚 combobox 到底怎么灌数据的新人——下面会从控件形态、取数结构、联动刷新、故障排查一路讲到能直接抄的代码骨架。1. 先认清 combobox 在 TIPTOP 里的三种存在形态很多同学写不出来动态下拉不是语法不会而是没分清手上这个「下拉框」到底是哪一种东西。TIPTOP 的界面层基于 Genero BDL 运行时combobox 至少有三种实现路径它们的生命周期、数据灌入时机、可用的 API 完全不同。选错形态后面所有努力都是白费。1.1 form 里声明成 COMBOBOX 类型的字段这是最容易被误认为「只能静态」的一种。在.frm或部分版本里的.per窗体档中把一个 item 的类型写成COMBOBOX编译后界面上就是一个带下拉箭头的输入框。它的特点是控件本身由窗体定义位置、大小、颜色都在 form 里画好4GL 只负责在运行时往里塞选项。这种形态最大的好处是和 TIPTOP 现有的窗体体系完全兼容——字段校验、必填、跳格顺序、BEFORE INPUT/AFTER INPUT事件全都照常工作不需要额外处理布局。很多老项目的下拉都是这么干的只是在BEFORE INPUT里用COMBOBOX语句一次性列出选项看起来就像写死的。实际上它完全可以动态化只要把选项来源换成变量或数组。需要建立的第一条认知是form 里声明 COMBOBOX 不等于静态选项内容由谁决定取决于你什么时候、用什么方式往里灌数据。1.2 运行时创建的自由控件Genero 提供的ui.ComboBox是一个可以完全在 4GL 代码里create出来的控件不依赖 form 声明。它的优势是灵活可以随时addItem、removeItem可以挂setDefaultInitializer做懒加载甚至可以在一个窗口里动态增删多个下拉框。代价是布局要自己管。要么通过setGeometry指定像素坐标窗口缩放时容易错位要么用DIALOG.addWidget把它挂进已有的 dialog 容器里。在 TIPTOP 这种窗体高度标准化的环境下纯代码建控件通常只用在「弹出的临时选择窗」或者「参数设定画面」这类场景主档维护界面还是走 form 声明的路子更稳。1.3 用 INPUT ARRAY 弹窗模拟下拉还有一种土办法不用 combobox点一下字段弹出一个小窗口里面是DISPLAY ARRAY的可滚动物件清单选中一行回填。这种做法在数据量上千条时反而比下拉好用因为可以带列头、可以多列显示、可以模糊查询。三种形态没有绝对优劣关键看数据量和交互诉求形态数据灌入方式适用数据量布局成本典型场景form 声明 COMBOBOXui.ComboBox.forName或 COMBOBOX 语句几十到几百条低窗体已画好单据头的供应商、部门、币别代码创建 ui.ComboBoxcreateaddItem几十到上千条中需定位或挂载参数画面、临时查询条件INPUT ARRAY 弹窗数组 DISPLAY ARRAY上千条以上高要单独做 form料号、客户、科目这类大主档我个人的取舍线是选项不超过 200 条走 combobox超过就走弹窗。原因很简单下拉展开后一屏最多显示十几条超过两三百条用户就得靠滚轮硬翻体验还不如一次弹个列表让人家看清楚列头。2. 数据从哪来取数策略决定了下拉的响应速度确定了形态接下来是核心问题——选项从数据库里怎么捞。这一步的选择直接决定用户点开下拉时是「秒开」还是「转圈三秒」。见过太多程序是在ON CHANGE里直接SELECT ... FROM customer一次性全捞数据量一上去整张单据都跟着卡。2.1 全量预载和按条件取数要分场景全量预载的意思是程序初始化时把整张主档读进内存数组之后所有下拉都从这个数组里筛。它的优点是快——内存遍历比数据库往返快一个数量级用户反复切换工厂、切换类别列表都能瞬间刷新。缺点是占内存而且主档如果在程序运行期间被别修改了界面上的数据会是旧的。按条件取数的意思是用PREPAREEXECUTE拼一条带WHERE的语句用户选了什么条件就捞什么。优点是永远拿最新数据缺点是每次联动都要走一次数据库。实务上的分界线看两点主档笔数和联动频率。几百笔以内、而且主档很少变动的部门、币别、付款条件、税率代码闭着眼睛全量预载上万笔而且变动频繁的客户、料号、员工老老实实按条件取但取的时候必须把WHERE条件卡死不能留空条件让人捞全表。提示按条件取数时如果前置条件还没填比如工厂没选宁可让下拉为空并给出提示也不要退化成无条件全捞。这条是性能事故的高发点。2.2 用动态数组承载 key/value 对承载列表的结构我会统一用一个动态数组每个元素是一组codename。动态数组的好处是长度可变不用预估上限clear()之后能反复重用。DEFINE g_arr_supp DYNAMIC ARRAY OF RECORD code STRING, name STRING END RECORD DEFINE g_arr_contact DYNAMIC ARRAY OF RECORD code STRING, name STRING END RECORD灌数据的标准写法FUNCTION load_supp_array(p_factory) DEFINE p_factory STRING DEFINE l_cnt INTEGER CALL g_arr_supp.clear() DECLARE cur_supp CURSOR FOR SELECT supp_no, supp_name FROM supp_master WHERE factory p_factory AND status Y ORDER BY supp_no FOREACH cur_supp INTO g_arr_supp[g_arr_supp.getLength() 1].* LET l_cnt l_cnt 1 END FOREACH RETURN l_cnt END FUNCTION这里有几个细节值得说。FOREACH ... INTO arr[arr.getLength()1].*这个写法可以边读边追加不用先算总数比SELECT COUNT(*)再FOR i 1 TO n少一次数据库往返。ORDER BY一定要写下拉的顺序对用户找东西的效率影响很大按编号排是最符合使用者习惯的实在不行按名称排也行但绝不能不给顺序让数据库自由发挥。另外status这类有效性条件别忘了。生产环境的主档里通常有大量停用数据如果不过滤下拉里会混进一堆早就该消失的供应商用户选错了才发现不能立账。这类问题在测试环境发现不了因为测试库的主档往往没几笔停用资料。2.3 显示值和存储值必须分开存这是新手最容易搞混的地方。下拉框在界面上显示的是「名称」但真正要存进数据库、传给下一个环节的是「编号」。如果只存一份数据你就得在显示的时候查一次、取值的时候反查一次代码又臭又长还容易错。正确做法是在数组里同时保留code和name加进 combobox 的时候用两个参数的addItemCALL l_cb.addItem(g_arr_supp[i].code, g_arr_supp[i].name)第一个参数是内部值用户看不见第二个参数是显示文本。取值的时候拿到的永远是内部值显示的时候永远是文本中间不需要任何转换。如果用老式的COMBOBOX语句它只接受显示文本的列表那就是「显示什么就取回什么」这时候就得保证显示文本本身唯一或者干脆显示「编号 名称」这种复合串取回后再用SUBSTR截出编号。相比之下addItem的两参数形式从源头就把问题解决了。3. 联动刷新主档一变下拉怎么跟着换级联下拉真正的难点不在「怎么灌数据」而在「什么时候灌、灌之前要不要清、清完之后旧值怎么办」。这三件事处理不好就会出现「选了工厂没选供应商却能把单子存进去」这种数据脏掉的问题。3.1 ON CHANGE 的触发时机与递归陷阱字段变更事件在DIALOG块里用ON CHANGE捕获。最常见的写法DIALOG ... ON CHANGE g_factory CALL reload_supp_combo(g_factory) CALL reload_contact_combo(NULL) END DIALOG这里有个容易被忽略的点ON CHANGE在用户每敲一个字符、每按一次方向键时都可能触发具体行为取决于控件的NOT NULL与触发配置。为了不做无用功函数入口先比对一下值有没有真的变化FUNCTION reload_supp_combo(p_factory) DEFINE p_factory STRING IF p_factory IS NULL THEN CALL clear_supp_combo() RETURN END IF IF p_factory g_last_factory THEN RETURN END IF LET g_last_factory p_factory CALL load_supp_array(p_factory) CALL fill_supp_combo() END FUNCTION用一个g_last_factory记住上次的条件值没变就直接返回。这一招在数据量大时能省掉大量重复查询尤其是用户按着方向键在工厂列表里来回扫的时候效果非常明显。还有一个更隐蔽的陷阱联动函数内部如果改了别的字段会触发那字段的ON CHANGE形成链式甚至环形触发。比如选完供应商自动带出付款条件付款条件一改又回头去重算供应商可用列表就会死循环。防御办法是加一个g_in_link标志位进入联动前置真、退出时置假链路上每个联动函数开头都先判断这个标志。3.2 重建列表的标准四步不管用哪种形态重建下拉都要按固定顺序走完四步少一步就出问题清空旧选项。ui.ComboBox用倒序removeItem逐个删老版本没有批量清空方法正序删会因为下标前移漏掉一半元素。重新取数。按上一步选定的策略重新读数组。灌入新选项。遍历数组addItem。处理当前值。要么置空要么回填一个合法的默认值。FUNCTION clear_supp_combo() DEFINE l_cb ui.ComboBox DEFINE i INTEGER LET l_cb ui.ComboBox.forName(form1.cb_supp) IF l_cb IS NULL THEN RETURN END IF FOR i l_cb.getItemCount() TO 1 STEP -1 CALL l_cb.removeItem(i) END FOR END FUNCTION FUNCTION fill_supp_combo() DEFINE l_cb ui.ComboBox DEFINE i INTEGER LET l_cb ui.ComboBox.forName(form1.cb_supp) CALL clear_supp_combo() FOR i 1 TO g_arr_supp.getLength() CALL l_cb.addItem(g_arr_supp[i].code, g_arr_supp[i].name) END FOR END FUNCTIONui.ComboBox.forName是打通 form 声明和代码操作的桥梁参数要写「窗体名.字段名」窗体名对不上会拿到NULL所以每次用之前判空是个好习惯。3.3 旧值残留的三种处理办法上游条件变了下游下拉里原来选中的值很可能已经不在新列表里了。这时候有三种选择直接清空最简单也最安全用户必须重新选。适合强关联的下游字段比如工厂改了供应商必须重选。尝试保留如果旧值在新列表里还能找到就保留选中找不到再清空。适合弱关联比如部门改了但成本中心大概率不变能省用户一次点击。回填默认值新列表只有一笔时自动选中。这个体验最好但要小心——只有一笔不代表就是用户想要的涉及金额、税率的字段不建议这么做。FUNCTION restore_or_clear(p_old_value) DEFINE p_old_value STRING DEFINE l_cb ui.ComboBox DEFINE i INTEGER LET l_cb ui.ComboBox.forName(form1.cb_supp) FOR i 1 TO g_arr_supp.getLength() IF g_arr_supp[i].code p_old_value THEN LET l_cb.value p_old_value RETURN END IF END FOR LET l_cb.value NULL END FUNCTION4. 五个高频故障的排查链路下面这几类问题我在不同项目里反复遇到每一个都值得单独拎出来说清楚排查顺序。直接给结论没意义重点是让你下次遇到类似现象时知道从哪一步开始怀疑。4.1 列表明明灌了界面却是一片空白现象是点开下拉没有任何选项但你在函数里加了DISPLAY打印数组长度明明大于零。排查顺序按这个来先确认ui.ComboBox.forName返回的引用不是NULL返回NULL就说明窗体名或者字段名拼错了这是最常见的原因再确认 form 里那个字段的类型确实编译成了COMBOBOX有些项目里 form 是从旧版本沿用的字段类型还是EDIT这种情况下forName可能拿到对象但addItem不生效最后确认 form 文件改完之后重新编译过——只编译 4GL 不重新编译 form界面上的控件类型永远不会变这个坑几乎每个新手都会踩一次。还有一个可能是setDefaultInitializer用得不当。这个机制是在下拉真正展开时才调用初始化函数如果你在BEFORE INPUT里灌了数据同时又挂了 initializer展开时 initializer 会重新跑一遍并可能把已有选项清掉。要么用 initializer 做懒加载要么在事件里手动灌别混着来。4.2 选完取值拿回来是编号不是名称这通常不是 bug而是设计如此。addItem(code, name)之后.value返回的就是code。如果业务上确实需要名称要么在数组里按code查一次要么在使用处直接取getItemText。真正需要警惕的是反过来的情况老代码用的是COMBOBOX语句显示什么取回什么某天有人把显示文本从「S001」改成了「S001 甲公司」所有依赖这个值做后续查询的地方全部失配而且编译期毫无提示。所以只要涉及「值会被存库或被别的模块引用」一定要用addItem的双参数形式把显示和存储解耦。4.3 联动之后旧值没清脏数据进了库表现是存盘成功但查出来发现「A 工厂的单子挂了个 B 工厂才有的供应商」。根因往往在联动时只重建了列表没处理value。排查的时候在ON CHANGE函数末尾加一行日志把清空后的value打出来。如果它还是旧值说明重建列表的时候没有显式置NULL——removeItem删的是选项不是当前值控件会保留那个已经不在列表里的字符串。这一点非常反直觉但确实是它的行为。配套的防御是在AFTER INPUT或存盘前做一次合法性校验拿当前value去数组里找一遍找不到就报错拦下。FUNCTION check_supp_valid(p_supp) DEFINE p_supp STRING DEFINE i INTEGER FOR i 1 TO g_arr_supp.getLength() IF g_arr_supp[i].code p_supp THEN RETURN TRUE END IF END FOR RETURN FALSE END FUNCTION4.4 数据量大时点开下拉要等好几秒下拉展开时卡顿来源通常有三处。一是灌数据时在循环里做了额外查询典型的 N1 问题数组里每一笔都去查一次名称一千笔就是一千次往返二是列表长度失控几千个选项塞进 combobox渲染本身就慢三是每次ON CHANGE都重新全量取数用户来回切几下就卡死。优化顺序先把循环内的查询全部提到外面用JOIN一次取完再给列表加个上限超过一定笔数就提示用户先输入关键字筛选最后用前面提到的g_last_xxx变量缓存上次条件值没变不重复取。补充一个容易被忽略的点ui.ComboBox的选项是全部一次性加载到客户端的。如果你有一万条主档即使用户只会选其中一条也要全部传过去。这种情况下应该改成「下拉只放常用值 弹窗查全部」的混合方案。4.5 同一个值出现两次选中后跳回第一条现象是列表里明明看得见你要选的那条点完却跳到了另一条同名的记录上。原因是addItem的第一个参数出现了重复控件按 value 定位时只会命中第一个。根因一般是 SQL 没去重或者JOIN之后主表被从表放大。检查方式很简单在灌数据前跑一遍SELECT code, COUNT(*) ... GROUP BY code HAVING COUNT(*) 1有结果就说明数据源本身不唯一。现象首要怀疑点快速验证方法下拉空白窗体名/字段名拼错打印forName返回值是否为NULL取值是编号用了双参数addItem检查.value与getItemText的用法旧值残留重建列表未置空value清空后打印.value展开卡顿循环内查询或选项过多统计数组长度与 SQL 执行次数选中跳转value 重复对数据源做GROUP BY查重5. 一套能直接落地的骨架客户—联系人级联下拉前面讲的都是零件这里拼一台能跑的整机。场景很典型单据头选客户明细或者联系人区块要跟着只显示该客户下的联系人。5.1 窗体与变量的声明form 里把两个字段都声明成COMBOBOX类型字段名分别叫cb_cust和cb_contact放在同一行。4GL 里的变量声明建议统一DEFINE g_cust_no LIKE customer.cust_no DEFINE g_contact_no LIKE contact.contact_no DEFINE g_arr_cust DYNAMIC ARRAY OF RECORD code STRING, name STRING END RECORD DEFINE g_arr_contact DYNAMIC ARRAY OF RECORD code STRING, name STRING END RECORD DEFINE g_last_cust STRING DEFINE g_in_link BOOLEANg_last_cust用来做条件缓存g_in_link防止联动递归。这两个变量看着不起眼但没有它们程序在真实数据量下的表现会差一个档次。5.2 初始化与两个联动函数初始化阶段把客户列表一次性预载进来FUNCTION init_cust_combo() DEFINE l_cb ui.ComboBox DEFINE i INTEGER CALL g_arr_cust.clear() DECLARE cur_cust CURSOR FOR SELECT cust_no, cust_name FROM customer WHERE status Y ORDER BY cust_no FOREACH cur_cust INTO g_arr_cust[g_arr_cust.getLength() 1].* END FOREACH LET l_cb ui.ComboBox.forName(form1.cb_cust) FOR i 1 TO g_arr_cust.getLength() CALL l_cb.addItem(g_arr_cust[i].code, g_arr_cust[i].name) END FOR END FUNCTION联系人联动则按条件实时取FUNCTION reload_contact_combo(p_cust) DEFINE p_cust STRING DEFINE l_cb ui.ComboBox DEFINE i INTEGER LET l_cb ui.ComboBox.forName(form1.cb_contact) IF l_cb IS NULL THEN RETURN END IF -- 倒序清空 FOR i l_cb.getItemCount() TO 1 STEP -1 CALL l_cb.removeItem(i) END FOR LET l_cb.value NULL IF p_cust IS NULL THEN CALL g_arr_contact.clear() RETURN END IF CALL g_arr_contact.clear() DECLARE cur_contact CURSOR FOR SELECT contact_no, contact_name FROM contact WHERE cust_no p_cust AND status Y ORDER BY contact_no FOREACH cur_contact INTO g_arr_contact[g_arr_contact.getLength() 1].* END FOREACH FOR i 1 TO g_arr_contact.getLength() CALL l_cb.addItem(g_arr_contact[i].code, g_arr_contact[i].name) END FOR END FUNCTION5.3 事件挂接与校验兜底DIALOG BEFORE INPUT CALL init_cust_combo() CALL reload_contact_combo(g_cust_no) ON CHANGE g_cust_no IF NOT g_in_link THEN LET g_in_link TRUE CALL reload_contact_combo(g_cust_no) LET g_in_link FALSE END IF BEFORE FIELD g_contact_no IF g_cust_no IS NULL THEN NEXT FIELD g_cust_no END IF END DIALOGBEFORE FIELD里拦住没选客户就想选联系人的操作比等用户填完再报错友好得多。存盘前的兜底校验也别省IF NOT check_contact_valid(g_cust_no, g_contact_no) THEN ERROR 所选联系人不属于当前客户请重新选择 NEXT FIELD g_contact_no END IF5.4 上线前的自测清单代码写完不要直接交给用户这几项自己先过一遍能省掉后面一堆返工客户切换三次以上联系人列表每次都是对应的集合没有残留。客户选完再清空如果允许联系人列表同步变空。客户 A 的联系人选好后切到客户 B联系人是否被清空。主档里新增一笔有效客户不重启程序能否在刷新后出现取决于是否取消预载。数据量最大的那个客户展开联系人下拉不卡顿。直接点存盘而不选任何下拉必填校验是否生效、报错信息是否指向正确字段。6. 再往前一步缓存、自动筛选与降级处理骨架跑通只是及格线真要在生产环境站住还有几件事值得做。6.1 把主档缓存到模块级数组客户列表、部门列表、币别列表这类几乎不变的主档在单体程序里可以缓存到模块级变量第一次取完之后就不再走数据库。做法是加一个g_cache_loaded标志初始化函数入口判断一下FUNCTION load_cust_cached() IF g_cache_loaded THEN RETURN END IF -- ... 取数逻辑 ... LET g_cache_loaded TRUE END FUNCTION要注意的是缓存的生命周期。如果是长驻的批处理程序缓存会导致主档更新后看不到新数据如果是常规单据画面一次会话内的缓存反而更符合用户预期——开单中途主档被别人改了界面不跟着跳是个好事。这个取舍要看具体业务没有统一答案。6.2 输入即筛选的简易实现下拉选项多的时候让用户输入前几个字符就能缩小范围体验提升非常明显。Genero 的 combobox 在部分配置下支持输入过滤但如果环境不支持可以用一个简单的降级方案在ON CHANGE里拿输入值去数组做LIKE匹配重建列表。FUNCTION filter_cust(p_keyword) DEFINE p_keyword STRING DEFINE l_cb ui.ComboBox DEFINE i INTEGER LET l_cb ui.ComboBox.forName(form1.cb_cust) FOR i l_cb.getItemCount() TO 1 STEP -1 CALL l_cb.removeItem(i) END FOR FOR i 1 TO g_arr_cust.getLength() IF p_keyword IS NULL OR g_arr_cust[i].code LIKE % || p_keyword || % OR g_arr_cust[i].name LIKE % || p_keyword || % THEN CALL l_cb.addItem(g_arr_cust[i].code, g_arr_cust[i].name) END IF END FOR END FUNCTION注意LIKE前面加通配符走不了索引但这是内存数组遍历不涉及数据库所以没有性能问题。这类过滤只适合几百条的量级上千条就要考虑把过滤下推到 SQL 里。6.3 取数失败时不要留下半截列表最后提一个容易被忽略的健壮性问题。如果因为主档被锁、网络抖动取数中途失败程序抛了异常跳出去此时 combobox 可能处于「已经清空但没灌新数据」的状态用户看到的是个空下拉还以为自己没有权限。稳妥做法是把「清空」和「灌入」放在同一个WHENEVER保护块里异常捕获后主动把列表恢复成一个安全的默认状态同时给出明确提示WHENEVER ERROR CALL clear_contact_combo() DISPLAY 联系人资料读取失败请稍后重试 RETURN END WHENEVER宁可让用户重新选一次也不要让他面对一个既空着又说不清原因的下拉框。我在几个项目上做过统计combobox 相关的客诉里超过六成集中在「联动后旧值没清」和「列表显示异常」这两类真正难的是把这几十行代码在合适的时机、以合适的顺序调用起来语法本身占的比重不到三成。所以建议在第一次动手时先把clear → load → fill → restore这四步写成一个固定套路之后再谈优化。另外改动 form 里的字段类型之后记得把 form 和 4GL 一起重新编译只编一边的排查成本比自己重写一遍还高。