Me.Dirty 在 Form_Dirty() 事件中为假!- VBA MS Access 2007

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/11291570/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-11 16:42:05  来源:igfitidea点击:

Me.Dirty is false within Form_Dirty() event! - VBA MS Access 2007

ms-accessvbaaccess-vba

提问by PeterZ

How do you tell if the form is dirty within the OnDirtyevent (MS Access 2007)?

如何在OnDirty事件 (MS Access 2007) 中判断表单是否脏?

Consider this simple example, I'm calling out to a subroutine to validate some buttons within the Form_Dirty()event.

考虑这个简单的例子,我调用一个子程序来验证Form_Dirty()事件中的一些按钮。

Private Sub Form_Dirty(Cancel As Integer)
    MsgBox Me.Dirty  
    ' The above line shows false, which makes the Me.Dirty property about as useful as tits on a bull!
    Call validateSaveCancelBtn
End Sub   

Private Sub validateSaveCancelBtn()
    btnCancel.ENABLED = Me.Dirty
    btnSave.ENABLED = Me.Dirty
End Sub

And please don't tell me to just stick the code from validateSaveCancelBtn()into Form_Dirty()and hard-code it in there. This is not gona work for me as I'm calling into the validateSaveCancelBtn() from other places too, and the actual logic is more complex than what I pasted here.

并且请不要告诉我只是将validateSaveCancelBtn() 中的代码粘贴到Form_Dirty() 中并在那里对其进行硬编码。这对我不起作用,因为我也从其他地方调用 validateSaveCancelBtn() ,实际逻辑比我在这里粘贴的更复杂。

回答by HK1

Assuming your form is a bound form, the form is absolutely guaranteed to be dirty on the Form's Dirty Event, although the Me.Dirty property will still be false at this point.

假设你的表单是一个绑定表单,这个表单绝对可以保证在表单的脏事件中是脏的,尽管此时 Me.Dirty 属性仍然是假的。

Here's how you work around this weird gotcha.

这是你如何解决这个奇怪的问题。

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

Everywhere else where you call validateSaveCancelBtn, just use this:

在您调用 validateSaveCancelBtn 的其他任何地方,只需使用以下命令:

Private Sub Form_AfterUpdate()
    Call validateSaveCancelBtn(Me.Dirty)
End Sub

Purely as a side note

纯粹作为旁注

I try to stay away from using the Visible and Enabled properties on Save/New/Cancel/Delete buttons. I find that it's much more foolproof to program the code behind each of those buttons so that it handles a button press differently (and properly) for every possible scenario.

我尽量避免在 Save/New/Cancel/Delete 按钮上使用 Visible 和 Enabled 属性。我发现对每个按钮后面的代码进行编程更加万无一失,以便它在每种可能的情况下以不同方式(并且正确地)处理按钮按下。

It's true that there is less feedback for the user if those buttons are always visible and enabled, making it appear that you can Save or Cancel even if there is nothing to Save or Cancel. Having said that, consider that Save and Cancel buttons in Access are basically broken right out of the box. Here's why:

确实,如果这些按钮始终可见并启用,那么用户的反馈就会减少,这使得即使没有要保存或取消的内容,您也可以保存或取消。话虽如此,考虑到 Access 中的“保存”和“取消”按钮基本上是开箱即用的。原因如下:

  1. A new record or changes to a record will be saved when the user closes the form
  2. A new record or changes to a record will be saved when a user moves to a subform
  3. Because of #2, a Cancel button will not be able to cancel changes on the Main Form once a user has moved to a subform. Neither can a cancel button on a main form cancel changes made to records on a subform because as soon as focus successfully shifts from the subform back to the main form, the subform record has been saved.
  1. 当用户关闭表单时,将保存新记录或对记录的更改
  2. 当用户移动到子表单时,将保存新记录或对记录的更改
  3. 由于#2,一旦用户移动到子表单,取消按钮将无法取消主表单上的更改。主窗体上的取消按钮也不能取消对子窗体上的记录所做的更改,因为一旦焦点成功地从子窗体转移回主窗体,子窗体记录就已保存。

I normally show a Save button and leave it visible and enabled all the time. It makes the user feel good to click it, and there's no harm in providing the button. I do actually put code behind it too, but I do not force the user to use the save button since there are other events (as mentioned) that will cause a Save to be fired.

我通常会显示一个保存按钮并让它始终可见并启用。点击它会让用户感觉很好,提供按钮也没有坏处。我实际上也把代码放在了后面,但我不会强迫用户使用保存按钮,因为还有其他事件(如上所述)会导致保存被触发。

I generally do not provide Cancel buttons because they are "broken" just as soon as you add a subform. I've been involved in numerous discussions about how to provide the user with a Cancel button that can cancel multi-record edits (basically, handle a form and subforms as a transaction). Probably one of the best methods, though still very involving to build, is to use Temporary Tables (basically pseudo-temporary tables, as Access doesn't actually have anything officially called a temporary table) to hold the records being added/edited. Then on the Save Button or on Form Close you have to actually write those records back to the real database. There's much more to it than that, but I'm just trying to give you a rough idea.

我通常不提供取消按钮,因为只要您添加子表单,它们就会“损坏”。我参与了许多关于如何为用户提供可以取消多记录编辑的“取消”按钮的讨论(基本上,将表单和子表单作为事务处理)。最好的方法之一可能是使用临时表(基本上是伪临时表,因为 Access 实际上没有任何正式称为临时表的东西)来保存正在添加/编辑的记录,尽管它仍然非常涉及构建,但可能是最好的方法之一。然后在 Save Button 或 Form Close 上,您必须实际将这些记录写回真实数据库。还有更多的东西,但我只是想给你一个粗略的想法。