列上的PowerBuilder表达式控制奇怪的行为

Question

我正在开发一个传统的PowerBuilder应用程序，我们已经升级到PowerBuilder 12但继续使用“经典”IDE。

我有一个网格DataWindow与自由格式DataWindow共享数据，两者都继承了祖先，确保当网格中当前行发生变化时，自由形式滚动到同一行。

我已开始在freeform中的列控件的Protect和Background.Color属性上使用表达式来模拟启用/禁用，以替代在rowfocuschanged上使用DataWindow.Modify。

到目前为止，我很喜欢这种方法，它似乎更清晰，并且没有明显的性能损失，因为我没有在任何表达式中访问数据库。

问题是，由于我很难确定原因，这些表达式有时会导致上述行同步功能失败。

在我的测试场景中，网格中有两行。选择第2行不会导致自由形式滚动到第2行，尽管调试显示ScrollToRow确实正常被调用。然后我再次选择第1行，不能确定这是否有效，因为自由形式从未离开第1行开始。然后我第二次选择第2行，并且自由形式正确地滚动到第2行，从此事情就变得花哨了。

我通过在一个特定表达式中移动代码，已经在不同的窗口上修复了这个问题，不知道为什么这个工作，这些更改不会影响表达式的结果。不幸的是，我没有这么容易的时间修复它在我当前的窗口。到目前为止，我可以通过从一个特定的DateTime EditMask列中删除Protect表达式，或者通过将前面的DateTime EditMask列的TabOrder设置为正值来解决功能丧失的问题。第一列需要Protect表达式，第二列需要不可编辑。我试图给第二列一个正TabOrder，同时将它的Protect表达式设置为1，但这不起作用。

我正在撕扯我的头发，讨厌PowerBuilder一些激烈的东西！如果有人知道问题是什么以及如何在避免使用列表达式的同时继续利用列表达式，我将不胜感激。我不愿意通过从rowfocuschanged修改来回去操纵这些东西。

Answer 1

回顾一下这里的答案，取消并添加评论中的内容。

当您设置新行时，PowerBuilder会尝试将列设置为当前在当前行中具有焦点的列。这在基本情况下工作正常，但是当Protect属性具有表达式时，事情可能会更难以预测。在目标行中的列受到保护的情况下，我不确定是否存在记录或预期的行为，但我的安全位置是行为不可预测，您可能不应该这样做这个。正如Mike已经证明的那样，明确设置该列可以解决他的问题。

如果您尝试解决类似问题，另一个要检查的主要事项是确保RowFocusChanging不返回1以防止发生行更改。

祝你好运，

特里。

Answer 2

我遇到了类似的问题，其中不仅字段受到保护，而且当行焦点改变时，背景和文本颜色也会改变。

出于某种原因，Datawindow表达式非常不一致，尤其是当存在其他样式（如复选框）时。从datawindow对象中删除所有这些表达式并将它们全部放在datawindow控件中的一个用户事件/函数中，使用Post（）从网格列表的rowfocuschanged（）事件中调用它似乎可以解决问题。此外，这样做可以让你更好地控制事件何时真正触发，而不是在dw表达式上有代码。