宜しくお願い致します
サブフォームから親フォームのレコード更新のため、Parent.refreshを行うとサブフォームの先頭レコードかつ先頭フィールドにフォーカスが移動してしまいます。
親フォームのレコード更新をフォーカスが移動せずに行なう方法はありますか？
Microsoft Access 掲示板
parent.refreshでレコードとフィールドの位置が先頭になってしまう。
17
コメント
views
4
フォロー
Parent.Requeryではなくて、Parent.Refresh で間違いないですか。
当方で簡単なサンプルを作成して試してみましたが、そのような現象は確認できませんでした。
Parent.refresh はサブフォームのどのイベントに記述してますか。そのイベントプロシージャ全体を提示してもらえますか。
hatena様、ご返答ありがとうございます。
先ほどは確かにフォーカスが移動してしまっていたのですが、いろいろコードをいじっていたらならなくなりました。
すみませんでした。
ですが、Parent.parent.refreshというのもあるのですが、
こちらは実行すると親フォーム（親の親ではなく）の先頭フィールドに移動してしまいます。
コードは以下の通りです。長すぎるので全ては載せきれません。
If Parent.Parent!書式ID <> 10 And Parent.Parent!書式ID <> 16 And Parent.Parent!書式ID <> 17 Then
Select Case Parent.Parent!書式ID
Case 1, 3, 5
Parent.Parent!巻替検査記録 = True ←チェックボックス（テーブルと連結）
Parent.Parent!巻替検査記録ボタン.Visible = True ←コマンドボタン
Parent.Parent.Refresh ←ここを処理すると画面の位置が上へ移動してしまいます。
追加です。
イベントは、Private Sub Form_AfterUpdate()
です。
一番親のフォームはテーブル連結で、いくつかのコマンドボタンとそのボタンの表示非表示の状態を示すチェックボックスがあります。
その子フォームは一番親フォームのボタンを押すと、指定のフォームがソースオブジェクトになり、画面が表示されるようになっています。
その子フォームの子フォームが帳票フォームになっております。そこからの処理です。
「先頭レコードかつ先頭フィールドにフォーカスが移動」
「先頭フィールドに移動」
「画面の位置が上へ移動」
複数の表現が混在していますが、現状の動作はどれでしょうか。
また、サブフォームの更新後処理で実行されているのなら、フォーカスはサブフォームにあるはずですので、「先頭フィールドにフォーカス移動」というのは、Refresh では発生するはずがないです。フォーカス移動させるような処理がどこかにあるのではないですか。
Parent.parent.refreshの問題に関しては、「先頭フィールドに移動」です。
先頭フィールドに移動し、それにつれて画面が上に移動します。
Parent.parent.refreshの部分でブレークポイントを設定し、そこまではフォームもそのままです。
しかし、ステップインし、コードを実行すると、画面が上に移動します（先頭フィールドに移動）。
処理の中にはSetfocus等の処理は全くありません。
別途、簡単なサンプルDBを作り、同じような構成（単票フォームの中に単票フォーム、その中に帳票フォーム）にしました。
その結果、一番子フォームの帳票フォーム内で、先頭レコードに移動する、という結果になりました。
Refreshでもレコードの移動があるようですが。
ファイルをアップできれば、見ていただけるかと思いますが、無理ですね。
孫フォームで入力してレコード保存すると(更新処理)、親フォーム(Parent.parent)にフォーカス移動して、画面がスクロールして、先頭フィールドへフォーカスが移動するということですか。
こちらで下記のようなサンプルを作成して実験してみましたが、症状は再現できませんでした。
親テーブル、子テーブル、孫テーブルを作成してサンプルデータを入力。
それぞれをソースとするフォームを作成して、親テーブルフォームに子テーブルフォームをサブフォームとして配置。
子テーブルフォームに孫テーブルフォーム(帳票フォーム)をサブフォームとして配置。
孫テーブルフォームの更新後処理に下記のように記述。
親フォームへフォーカス移動しませんでした。
かなり複雑なことをしているようですし、こちらで状況を再現できないので、こちらから原因を特定するのは困難です。
まずは、現状の各フォームのコードをコメントアウトして、孫フォームの更新後処理の下記の部分だけコメントアウトを解除してサブフォームで更新してShift+Enterでレコード保存した場合、症状は出ますか。
上記の回答を書いてから下記の追記に気が付きました。
孫フォームで先頭レコードへ移動するという現象ですか。
それなら、当方のサンプルでも現象を再現できました。
ちょっと対策を検討してみますのでお待ちください。
hatena様、ありがとうございます。
ご指示の内容を行なってみましたが、やはり症状は出ます。
なお、
「孫フォームで入力してレコード保存すると(更新処理)、親フォーム(Parent.parent)にフォーカス移動して、画面がスクロールして、先頭フィールドへフォーカスが移動するということですか。」
について。
親フォーム(Parent.parent)にフォーカス移動して → 中間のフォーム（Parent）にフォーカス移動して
です。
すみません。遅くなりましたが、大事なことを伝え忘れていました。
テーブルはSQL ServerよりODBCリンクです。
３階層のサブフォーム構成の場合、一番上のフォームでRefreshすると、３番目のサブフォームは再読込されるという仕様のようです。なぜこのような仕様なのか１ユーザーからは伺いすることはできませんが、各リンクテーブルのデータ整合性を保つために必要なことなのかもしれません。どちらにしても、このような内部処理をユーザーから変更するのは難しいかと。
とりあえず、当方のサンプルでは、
というようにRefreshをコメントアウトしておくと、先頭レコードへ移動せずにチェックが入りました。
ただし、テーブルにはすぐには反映せずに、メインフォームへフォーカスを移動するとテーブルに反映されました。
※「チェック1」はチェックボックス名
Accessのローカルテーブルでの確認ですので、SQL Serverだと動作が異なるかもしれません。
なるほど。そういう仕様もあるのですね。
ユーザーからは制御不能ですよね。
Parent.parent.Refreshを行わないと、すぐにはテーブルに反映しないのが引っかかります。
フォーカスを移動するなど、レコードを保存するタイミングにならないと保存されないと、
それまでの間にAccessがクラッシュやフリーズした際にレコードが保存されないのが問題になりますよね？
以下のどちらかを取るかと思っています。
Refreshをして、レコードが移動してしまい、ユーザー操作がやりづらくなったり入力ミス等が発生するかもしれないが、データの完全性を保持する事を優先するか。
Refreshをせず、レコードが移動しないことで、ユーザー操作に影響がないが、データの完全性に大きなリスクを背負わせるか。
hatena様ならどちらを取りますか？それとも他のお考えがございますか？
これを気にするなら、Parent.parentのチェックボックスは非連結にしておいて、レコードソースのテーブルのフィールドを更新クエリかDAOまたはADOで直接更新するようにすればどうでしょう。
DAOで、フォームのレコードセットのコピーを生成して、それに対して更新する方法でどうだろう。
Chk はレコードソースのフィールド名
Chk１ はチェックボックス名(非連結)
チェックボックスは非連結なので、親フォームのレコード移動時にフィールド値を代入するなどの処理は別に必要。
ちょっと今出先なので、サンプルで動作確認してはしていませんので、うまくいくかは不確定。
分かりました。
DAOの方法でやってみます。
他の作業が入ってきたので、やってみたら、またご連絡いたします。
ありがとうございます。
DAOの方法でうまくいきました。
Recordset.Cloneのおかげで、フォーカスが移動せずに済んでいます。
ありがとうございました。
うまく行きましたか。それはよかった。
前の回答でも書きましたが、チェックボックスは非連結なので、レコード移動時やユーザーがチェックボックスを更新した場合にテーブルと同期させる処理は必要なのでご留意ください。