3

私はレガシーPowerBuilderアプリに取り組んでおり、PowerBuilder 12にアップグレードしましたが、引き続き「クラシック」IDEを使用しています。

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

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

これまでのところ、私はこのアプローチを楽しんでいますが、それははるかにクリーンに見え、どの式でもデータベースにアクセスしていないため、明らかなパフォーマンスの低下はありません。

問題は、ピン留めに苦労しているという理由で、これらの式が原因で前述の行同期機能が失敗することがあることです。

私のテストシナリオでは、グリッドに2つの行があります。行2を選択しても、デバッグによってScrollToRowが実際に正常に呼び出されていることが明らかになったにもかかわらず、フリーフォームが行2にスクロールすることはありません。次に、行1をもう一度選択します。これが機能するかどうかはわかりません。これは、フリーフォームが最初から行1を離れることがないためです。次に、行2をもう一度選択すると、フリーフォームが行2に適切にスクロールします。これ以降、物事はダンディになります。

ある特定の式内でコードを移動することにより、この問題を別のウィンドウで修正しました。これが機能した理由はわかりません。変更は式の結果に影響しませんでした。残念ながら、現在のウィンドウで修正するのは簡単ではありません。これまでのところ、特定のDateTime EditMask列からProtect式を削除するか、前のDateTime EditMask列のTabOrderを正の値に設定することで、機能が失われる問題を解決できます。最初の列にはProtect式が必要であり、2番目の列は編集不可である必要があります。Protect式を1に設定しているときに、2番目の列に正のTabOrderを指定しようとしましたが、機能しませんでした。

私は髪を引き裂いて、PowerBuilderに何か激しいものが嫌いです！問題が何であるか、そしてそれを避けながら列式を利用し続ける方法を誰かが知っていれば幸いです。rowfocuschangedからModifyを使用して、このような操作に戻るのは嫌です。

4

2 に答える 2

2

振り返ってみると、コメントで作成されたものから引用して追加した答えがここにあります。

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

同様の問題を解決しようとしている場合に確認するもう1つの主要なことは、行の変更が発生しないようにRowFocusChangingが1を返さないことを確認することです。

幸運を、

テリー。

于 2012-01-03T14:57:35.280 に答える
1

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

何らかの理由で、特にチェックボックスなどの他のスタイルがある場合、データウィンドウ式は非常に一貫性がありません。これらすべての式をデータウィンドウオブジェクトから削除し、Post（）を使用してグリッドリストのrowfocuschanged（）イベントから呼び出されるデータウィンドウコントロールの1つのユーザーイベント/関数にすべてを配置すると、うまくいくようです。また、この方法を実行すると、dw式にコードを設定するのではなく、イベントが実際に発生するタイミングをより細かく制御できます。

于 2012-01-04T00:16:30.550 に答える