フォームがバインドされたフォームであると仮定すると、この時点で Me.Dirty プロパティはまだ false ですが、フォームは Form の Dirty イベントでダーティであることが絶対に保証されます。
この奇妙な落とし穴を回避する方法は次のとおりです。
Private Sub Form_Dirty(Cancel As Integer)
Call validateSaveCancelBtn(True)
End Sub
Public Sub validateSaveCancelBtn(bDirty as Boolean)
btnCancel.Enabled = bDirty
btnSave.Enabled = bDirty
End Sub
validateSaveCancelBtn を呼び出す他の場所では、これを使用するだけです。
Private Sub Form_AfterUpdate()
Call validateSaveCancelBtn(Me.Dirty)
End Sub
純粋に補足として
[保存]、[新規作成]、[キャンセル]、[削除] ボタンで Visible および Enabled プロパティを使用しないようにしています。これらの各ボタンの背後にあるコードをプログラムして、考えられるすべてのシナリオでボタンの押下を異なる方法で (そして適切に) 処理する方がはるかに確実であることがわかりました。
これらのボタンが常に表示され有効になっていると、ユーザーへのフィードバックが少なくなるため、保存またはキャンセルするものがない場合でも、保存またはキャンセルできるように見えます。そうは言っても、Access の [保存] ボタンと [キャンセル] ボタンは、基本的にすぐに壊れていることを考慮してください。理由は次のとおりです。
- ユーザーがフォームを閉じると、新しいレコードまたはレコードへの変更が保存されます
- ユーザーがサブフォームに移動すると、新しいレコードまたはレコードへの変更が保存されます
- #2 のため、ユーザーがサブフォームに移動すると、キャンセル ボタンはメイン フォームの変更をキャンセルできません。サブフォームのレコードに加えられた変更をメイン フォームのキャンセル ボタンでキャンセルすることもできません。これは、フォーカスがサブフォームからメイン フォームに正常に戻るとすぐに、サブフォームのレコードが保存されるためです。
私は通常、[保存] ボタンを表示し、常に表示して有効にしたままにします。ユーザーはクリックして気分が良くなり、ボタンを提供しても害はありません。実際にはコードも背後に置いていますが、(前述のように) 保存を発生させる他のイベントがあるため、ユーザーに保存ボタンの使用を強制しません。
サブフォームを追加するとすぐに「壊れる」ため、通常、キャンセル ボタンは提供しません。複数レコードの編集をキャンセルできる [キャンセル] ボタンをユーザーに提供する方法 (基本的には、フォームとサブフォームをトランザクションとして処理する) について、数多くの議論に参加してきました。おそらく最良の方法の 1 つは、作成に非常に手間がかかりますが、追加/編集されるレコードを保持するために一時テーブル (Access には実際には一時テーブルと呼ばれるものがないため、基本的に疑似一時テーブル) を使用することです。次に、[保存] ボタンまたは [フォームを閉じる] で、実際にそれらのレコードを実際のデータベースに書き戻す必要があります。それだけではありませんが、大まかなアイデアを提供しようとしています。