jwcolby
jwcolby at colbyconsulting.com
Mon Aug 8 07:56:07 CDT 2011
IIRC the reason I got into this was that if AllowEdits is false no events (after update kind of things) will fire. Oddly the OnEnter kind of events do fire. Thus I am using the onEnter / OnExit to turn on / off .AllowEdits just long enough to enable a record selector to see it's AfterUpdate. Kludgy I know. John W. Colby www.ColbyConsulting.com On 8/8/2011 7:28 AM, Jim Dettman wrote: > > My guess is that it needs a fresh record and wants to place a read lock to > detect if it is currently being edited by another user. > > Jim. > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Benson > Sent: Sunday, August 07, 2011 01:12 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Setting .AllowEdits programmatically > > Maybe because the record source has to be rechecked to see if it is an > editable recordset? > On Aug 7, 2011 12:13 AM, "jwcolby"<jwcolby at colbyconsulting.com> wrote: >> Causes the current event to fire. >> >> I was running code >> >> .AllowEdits = mblnFrmEditMode >> >> and the current would fire immediately. I ended up having to wrap the code > in the following to >> *minimize" the current event firing even when it was already the same > state. >> >> If .AllowEdits<> mblnFrmEditMode Then >> .AllowEdits = mblnFrmEditMode >> End If >> >> No idea why this happens but it does. I also have no idea whether setting > the .AllowDelete and >> .AllowAdd causes a current event to fire. >> >> -- >> John W. Colby >> www.ColbyConsulting.com >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com