[AccessD] Checkbox dates

jwcolby jwcolby at colbyconsulting.com
Sun Jul 15 12:55:15 CDT 2007


A.D.

It did indeed relate to single form view.  This is a data entry screen of a
fairly complex record where continuous view simply doesn't work well.


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.TEJPAL
Sent: Sunday, July 15, 2007 10:08 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Checkbox dates

Steve,

    LOL! - Unbound checkbox was envisaged in John's original post. My
comments were in that context, and by way of further elaboration of the
course of action favored by you. 

    Apparently, the scenario as originally presented, related to single form
view. John has perfected a fascinating approach to form related matters. As
stated by him, there are so many ways to meet the objectives, making Access
all the more interesting.

Best wishes,
A.D.Tejpal
---------------

  ----- Original Message -----
  From: Steve Schapel
  To: Access Developers discussion and problem solving
  Sent: Sunday, July 15, 2007 11:49
  Subject: Re: [AccessD] Checkbox dates


  A.D.,

  Not wishing to imply that I disagree with you in any way, because I like
what you are suggesting.  However...

  A.D.TEJPAL wrote:
  > ... If the form happens to be in
  > continuous form or datasheet view, an unbound check box would be
untenable, leading to absurd display.

  Just to be clear that I was not suggesting a totally unbound checkbox on
the form, but rather one whose Control Source is like this:
  =[TheDateField] Is Not Null

  This serves the purpose of displaying, even on a continuous view form,
whether the date has been recorded for each record.  And equally, the code I
suggested earlier, on the Enter event of the checkbox, can be used to manage
the date data.

  I am just relating to how I have done this type of process in the past. 
  I am certainly not claiming that it is superior to yours or John's
  suggested approaches.  But I do know that it has effectively and simply
served the purpose for me in various scenarios.

  Next time I need this type of functionality, I will be considering the
  idea of an extra (redundant ;-) ) field in the table, as you have
described.

  Regards
  Steve
--
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