Results 1 to 11 of 11
  1. #1
    Join Date
    Feb 2013
    Posts
    6

    Red face Unanswered: Changing AlternateBackgroundColor casues save prompt

    Hello,
    This will be my first post on this forum.

    I have just encountered this problem for the first time.
    Changing the AlternateBackgroundColor via code at runtime causes the user to prompted to save changes to the form when it is closed. I have encountered this problem when changing other properties. For the most part I only manipulate properties that have existed in earlier versions of access. The AlternatebackgroundColor property was added with Access 2007. The problem may or may exist for other 200 or later properties as well - I looked into other newer properties yet.
    When so prompted the natural instinct of most users is to say 'Yes' since they are concerned abbout lossing data; the default state of the form including it's recordset (if this was changed dynamically) is then permanently altered.

    Take out the line:
    Me.AlternatebackgroundColor = XXXXX

    and all works as it should. Reinsert it and we're back to asve form prompt.
    The line was in a public function of a subform.

    Any help would be much appreciated.

    Thank you.

  2. #2
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Why not set the RecordSource in the Form_Open event?

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  3. #3
    Join Date
    Feb 2013
    Posts
    6

    Red face

    Thanks for the reply, but the subform recordsource property that is changed based selctions made on the main form. However, that is not the the casue of the problem. Even if the record source is set in advance and never changed but the alternatebackgroundcolor property of the detail section of the subform is changed then when the user closes the form, by any method, a dialog box opens asking the user if the want to save the changes.

    You want this to happen if you open a form in design or layout view and make changes to the form but it should not happen when a form is opened in form view and is only changed by running code.

    G

  4. #4
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    Set the AllowDesignChanges property of the concerned form to False.
    Have a nice day!

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    you could make certain the colours are set as they should be on close of the form and turn off warnigns when you close

    however it does suggest you are allowing your users to use the MDB on not following good practice of allowing users to use only an encrypted (MDE) version of the front end..
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by Sinndho View Post
    Set the AllowDesignChanges property of the concerned form to False.
    Unfortunately, this Property was removed from the Property Pane in 2007! To make it worse, the Property still exists, is set, by default to 'True' (allow changes, in all Views) and can only be set to 'No' in code if the Form is opened in Design View.

    Users frequently do odd things, but it seems particularly odd for one to change the AlternateBackgroundColor Property at runtime!

    Linq ;0)>
    Last edited by Missinglinq; 02-20-13 at 11:01.
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  7. #7
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by GTF View Post

    ...if the record source is set in advance and never changed but the alternatebackgroundcolor property of the detail section of the subform is changed then when the user closes the form, by any method, a dialog box opens asking the user if the want to save the changes....
    Sorry, but because of this

    ...the natural instinct of most users is to say 'Yes'...the default state of the form including it's recordset (if this was changed dynamically) is then permanently altered...
    I thought that the big concern was the incidental changing of the RecordSource!

    I suspect that the use of a mde/accde, for the Front End, is going to be the easiest way of doing this.

    An alternative approach would be to
    1. Change the Form from Datasheet View Form to Continuous View
    2. Tweak the design so that it looks like a Datasheet View Form
    3. Set the Close Button Property to 'No'
    4. Create a custom 'Close Form' button using the code below
    Code:
    Private Sub CmdCloseForm_Click()
    
    If Me.Dirty Then Me.Dirty = False
     DoCmd.Close , , acSaveNo
    End If
    
    End Sub

    The acSaveNo parameter keeps Access from saving any design changes, and will suppress the popup message.

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  8. #8
    Join Date
    Feb 2013
    Posts
    6
    Quote Originally Posted by Missinglinq View Post
    Sorry, but because of this


    I thought that the big concern was the incidental changing of the RecordSource!

    I suspect that the use of a mde/accde, for the Front End, is going to be the easiest way of doing this.

    An alternative approach would be to
    1. Change the Form from Datasheet View Form to Continuous View
    2. Tweak the design so that it looks like a Datasheet View Form
    3. Set the Close Button Property to 'No'
    4. Create a custom 'Close Form' button using the code below
    Code:
    Private Sub CmdCloseForm_Click()
    
    If Me.Dirty Then Me.Dirty = False
     DoCmd.Close , , acSaveNo
    End If
    
    End Sub

    The acSaveNo parameter keeps Access from saving any design changes, and will suppress the popup message.

    Linq ;0)>
    Thanks, but I tried that already, when the same dialog opens and it removes the main form as one of the items to be saved in the dialog but the subform is still listed.

    Yes MDE/ACCDE may be the easiest approach and I will get there. No one is using it yet; I'm just testing as I go and this shouldn't be happening. Something is amiss in the way Microsoft have implemented the additional properties added from 2007 - at least with this property anyway.

  9. #9
    Join Date
    Feb 2013
    Posts
    6
    Quote Originally Posted by Sinndho View Post
    Set the AllowDesignChanges property of the concerned form to False.
    It is set to false, unfortunately - I thought for a few seconds I may have something obvious there, but alas no.

  10. #10
    Join Date
    Feb 2013
    Posts
    6
    Quote Originally Posted by healdem View Post
    you could make certain the colours are set as they should be on close of the form and turn off warnigns when you close

    however it does suggest you are allowing your users to use the MDB on not following good practice of allowing users to use only an encrypted (MDE) version of the front end..
    Thanks; This version is not in use yet - just me testing as I go, but I know from early versions (this functionality since removed) that users will click 'yes' to save when prompted.

    MDE will likely solve the problem but it shouldn't be happening. Something is amiss with the way this property has been implemented by MS.

  11. #11
    Join Date
    Feb 2013
    Posts
    6
    Quote Originally Posted by Missinglinq View Post
    Unfortunately, this Property was removed from the Property Pane in 2007! To make it worse, the Property still exists, is set, by default to 'True' (allow changes, in all Views) and can only be set to 'No' in code if the Form is opened in Design View.

    Users frequently do odd things, but it seems particularly odd for one to change the AlternateBackgroundColor Property at runtime!

    Linq ;0)>
    Yeah I know, I'm fussy, I like the interface to look good - It's really just cosmetic but makes for a better user experience (IMO). When the data is marked as archival the background colors change to highlight this fact. The alternate color that looks good for current data looks pretty yuk against the archival background color. If I can't solve this I will either leave it out or look for a compromise color.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •