列のPowerBuilder式が異常な動作を制御します

Question

私は従来のPowerBuilderアプリケーションで作業していますが、PowerBuilder 12にアップグレードしましたが、引き続き「従来の」IDEを使用しています。

フリーフォームのデータウィンドウとデータを共有するグリッドデータウィンドウがあり、グリッド内の現在の行が変更されたときにフリーフォームが同じ行にスクロールすることを保証する祖先を継承しています。

rowfocuschangedでDataWindow.Modifyを使用する代わりに、フリーフォームの列コントロールのProtectおよびBackground.Colorプロパティで式を使用して、有効/無効をシミュレートすることを開始しました。

これまで私はこのアプローチを楽しんできました。私の表現の中でデータベースにアクセスしていないので、明らかにパフォーマンスが低下することはありません。

問題は、私が苦労してピンチダウンしているという理由で、これらの表現が前述の行同期機能を失敗させることがあります。

私のテストシナリオでは、グリッドに2つの行があります。行2を選択しても、フリーフォームが行2にスクロールすることはありません。実際には、ScrollToRowが実際に正常に呼び出されていることがデバッグによって明らかになっています。次に、行1をもう一度選択します。フリーフォームが最初に行1を残していないので、これが機能するかどうかはわかりません。その後、2行目を2回目に選択すると、フリーフォームは2行目までスクロールして正しく動作します。

特定の式の中でコードを移動することで別のウィンドウにこの問題を修正しましたが、これがなぜ機能したのかわかりません。変更は式の結果に影響しませんでした。残念ながら、私は現在のウィンドウでそれを固定するような簡単な時間を持っていません。これまで、ある特定のDateTime EditMask列からProtect式を削除するか、先行するDateTime EditMask列のTabOrderを正の値に設定することで、機能が失われたときに問題を解決できます。最初の列は保護式を必要とし、2番目の列は編集不可能でなければなりません。私は2番目の列に正のTabOrderを与えようとしましたが、保護式を1に設定しても動作しませんでした。

私は髪を引き裂き、PowerBuilderを激しく憎んでいます！問題が何であるか、そしてそれを避けながら列表現をどのように引き続き利用できるかについて誰かが分かっていれば、感謝します。私は、rowfocuschangedからModifyを使ってこのようなものを操作することに戻って嫌です。

Answer 1

ここでは、コメントで作成された内容を取り上げ、追加した答えを示します。

新しい行を設定すると、PowerBuilderは現在の行に現在フォーカスを持っている列と同じ列に列を設定しようとします。これは基本的なケースではうまくいきますが、Protect属性に式がある場合は、予測できないことがあります。宛先行の列が保護されている場合に文書化された動作または意図された動作があるかどうかはわかりませんが、安全性の私の立場は動作が予測できないということです。 Mikeが証明しているように、明示的に列を設定すると、彼の問題は解決されます。

同様の問題を解決しようとしているかどうかをチェックするもう1つの重要な点は、行の変更が発生しないようにRowFocusChangingが1を戻していないことを確認することです。

幸運、

テリー。

Answer 2

フィールドが保護されているだけでなく、行のフォーカスが変更されたときに背景とテキストの色が変更されるという同様の問題が発生しました。

特に、チェックボックスのような他のスタイルがある場合、Datawindowの式はかなり矛盾しています。データウィンドウオブジェクトからこれらの式をすべて削除し、Post（）を使用してグリッドリストのrowfocuschanged（）イベントから呼び出されるデータウィンドウコントロールの1つのユーザイベント/関数にそれらをすべて入れることは、このトリックを行うようです。また、このようにすることで、dw式にコードを記述するのではなく、いつイベントを実際に実行するかをより詳細に制御できます。