[AccessD] Dirty property

Bill Benson bensonforums at gmail.com
Thu Jul 23 16:48:45 CDT 2015


I have to disagree with part of that answer Steve. The Close event does NOT
need to fire if the Unload event has cancel in it - which it could and
would if you set a flag in the Before_Update event which causes it to bail
in a graceful manner (ie, by sending them an error in the Form_Error event,
and then the Cancel =True in the Unload Event if they were not to be
permitted to close the form via the close button.

I have no problem with the close button in this case. Admittedly I have not
played with it that long, but I have to ask, have you even tried the
combination of testing whether any of the required fields are empty in the
Form's Before_)Update event, and if not all populated, setting a boolean
flag that will void the Unload event?

I am sensing resistance to this method before anyone has proved it to be
worth disregarding. To me it seems quite robust, but this is the last time
I am going to champion it - because ... I DO NOT USE BOUND FORMS LOL.

On Thu, Jul 23, 2015 at 5:20 PM, Steve Schapel <
steve at datamanagementsolutions.biz> wrote:

> Hi Susan
>
> Your conclusion is correct, but the rationale not quite right.  I think
> you are assuming that the form's Close event is directly connected to the
> Close button in the form's Control Box.  It's not.  If that Close button is
> visible (which incidentally I never allow), and if it's clicked, there is a
> series of form events that are triggered.  Probably AfterInsert in the case
> of a new record, followed by BeforeUpdate, AfterUpdate, Unload, and then
> Close.  Don't quote me on the exact details ... but, you get the idea.  So,
> the point is, that by the time the form's Close event comes around, the
> record has already been saved, and therefore that event is too late in the
> process to be testing for the value of the Dirty property - by that time it
> will always be False, not because you "cancel the current state of the
> form", but because the record has been saved and therefore it is not Dirty.
>
> Regards
> Steve
>
>
> -----Original Message----- From: Susan Harkins
> Sent: Thursday, July 23, 2015 12:34 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Dirty property
>
> Well I don't mean to start anything, but I an willing to learn. What I
> think you're saying is... Access assumes when you click the Close button
> that you want to cancel the current state of the form... and thus... the
> Dirty property will also be False. If this is correct, I know how to
> proceed and I'm glad for the discussion. :) I'm just going to disable the
> Close button. :)
>
> Susan H.
>
> On Wed, Jul 22, 2015 at 7:46 PM, Darryl Collins <
> darryl at whittleconsulting.com.au> wrote:
>
>  This is why you want to use unbound controls, as they behave as the user
>> would expect - not as the database does.  When a user 'cancels' a form
>> they
>> expect the record to be dropped.  This is not the case when using a bound
>> form.
>>
>> Naturally this topic (bound/unbound) often ignites a firefight - so sorry
>> for bringing it up, but that is my experience and one of the many reasons
>> I
>> use unbound forms.
>>
>> Cheers
>> Darryl.
>>
>> -----Original Message-----
>> From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
>> Susan Harkins
>> Sent: Thursday, 23 July 2015 8:52 AM
>> To: Access Developers discussion and problem solving
>> Subject: Re: [AccessD] Dirty property
>>
>> So, usurping the form's Close event doesn't keep it from saving -- that's
>> confusing to me. What am I missing? Why would the Close button save the
>> record? I expect it to prompt me, not automatically save.
>>
>>
>>  --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list