 | |
#11
 
| |||
| |||
|
Re: ForeColor <> Expected? -
01-10-2011
, 12:24 PM
|
The addition of the innocuous change to the form's design was a workaround because it does set Access' internal "dirty" flag and all the changes are then saved. I'm thinking this should be tested in A2010 and reported to MS if it's still present. *IMNSHO this is a bug and not a feature. Tony -- |
I hope it is NOT a bug.
In the development environment I define and change forms, and these
changes ARE saved. The changes I do directly in the forms manually, so
no code.
In the production environment every form that is opened is tuned
through code, depending on meta data, specific user and context of the
form. These changes MAY NOT be saved, because the only effect would be
bloating of the database, and subsequent increased chances to go
corrupt.
Imb.
#12
| |||
| |||
|
|
The addition of the innocuous change to the form's design was a workaround because it does set Access' internal "dirty" flag and all the changes are then saved. I'm thinking this should be tested in A2010 and reported to MS if it's still present. *IMNSHO this is a bug and not a feature. Tony -- Hi Tony, I hope it is NOT a bug. In the development environment I define and change forms, and these changes ARE saved. The changes I do directly in the forms manually, so no code. In the production environment every form that is opened is tuned through code, depending on meta data, specific user and context of the form. These changes MAY NOT be saved, because the only effect would be bloating of the database, and subsequent increased chances to go corrupt. |
The problem is ONLY when the form is in Design View. The
code is NOT part of the form's module, it's in a wizard like
procedure that's only used as a design time helper when the
same change needs to be made to a bunch of controls and/or a
bunch of forms.
It IS a bug and I will report it when I can find time to get
my A2010 machine squared away and verify that the problem
still exists.
--
Marsh
#13
| |||
| |||
|
|
imb wrote: The addition of the innocuous change to the form's design was a workaround because it does set Access' internal "dirty" flag and all the changes are then saved. I'm thinking this should be tested in A2010 and reported to MS if it's still present. IMNSHO this is a bug and not a feature. Tony -- Hi Tony, I hope it is NOT a bug. In the development environment I define and change forms, and these changes ARE saved. The changes I do directly in the forms manually, so no code. In the production environment every form that is opened is tuned through code, depending on meta data, specific user and context of the form. These changes MAY NOT be saved, because the only effect would be bloating of the database, and subsequent increased chances to go corrupt. How do I make this less confusing? The problem is ONLY when the form is in Design View. *The code is NOT part of the form's module, it's in a wizard like procedure that's only used as a design time helper when the same change needs to be made to a bunch of controls and/or a bunch of forms. It IS a bug and I will report it when I can find time to get my A2010 machine squared away and verify that the problem still exists. -- Marsh- Hide quoted text - - Show quoted text - |
Apparently Access needs some kind of manual trigger to set the form in
a “to_save” state.
Another situation where there is a difference between the manual
update and the update through code, is the update of a control on a
form.
In the manual way the update triggers the BeforeUpdate and AfterUpdate
events of the control, whereas this does not happen in an update
through code.
So if you want to have the same effect before or after update of a
control, both manually and with code, it has no sense to use the
BeforeUpdate and AfterUpdate events, because it covers only part of
the updates (unless you have duplicate routines for manual updates and
updates through code).
Imb.
#14
| |||
| |||
|
|
On Jan 11, 12:15*am, Marshall Barton <marshbar... (AT) wowway (DOT) com> wrote: imb wrote: The addition of the innocuous change to the form's design was a workaround because it does set Access' internal "dirty" flag and all the changes are then saved. I'm thinking this should be tested in A2010 and reported to MS if it's still present. IMNSHO this is a bug and not a feature. I hope it is NOT a bug. In the development environment I define and change forms, and these changes ARE saved. The changes I do directly in the forms manually, so no code. In the production environment every form that is opened is tuned through code, depending on meta data, specific user and context of the form. These changes MAY NOT be saved, because the only effect would be bloating of the database, and subsequent increased chances to go corrupt. How do I make this less confusing? The problem is ONLY when the form is in Design View. *The code is NOT part of the form's module, it's in a wizard like procedure that's only used as a design time helper when the same change needs to be made to a bunch of controls and/or a bunch of forms. It IS a bug and I will report it when I can find time to get my A2010 machine squared away and verify that the problem still exists. Apparently Access needs some kind of manual trigger to set the form in a “to_save” state. Another situation where there is a difference between the manual update and the update through code, is the update of a control on a form. In the manual way the update triggers the BeforeUpdate and AfterUpdate events of the control, whereas this does not happen in an update through code. So if you want to have the same effect before or after update of a control, both manually and with code, it has no sense to use the BeforeUpdate and AfterUpdate events, because it covers only part of the updates (unless you have duplicate routines for manual updates and updates through code). |
modification events you are talking about now behave exactly
the way they are supposed to behave and have nothing
whatsoever to do with using a VBA utility procedure to help
design a form.
--
Marsh
#15
| |||
| |||
|
|
You are confusing two totally different things. *The DATA modification events you are talking about now behave exactly the way they are supposed to behave and have nothing whatsoever to do with using a VBA utility procedure to help design a form. |
In fact these are two totally different things.
Imb.
#16
| |||
| |||
|
|
I'm thinking this should be tested in A2010 and reported to MS if it's still present. IMNSHO this is a bug and not a feature. |
production app (you wouldn't be changing properties in design view),
I can definitely see coding up a utility to go through and set this
property in forms uniformly, so it's quite justified that it should
work correctly.
It was a long time before I used conditional formatting, and it
seems like a pretty poorly implemented feature to me.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#17
| |||
| |||
|
|
It was a long time before I used conditional formatting, and it seems like a pretty poorly implemented feature to me. |
was quite impressive if I say so myself. <smile>
http://autofeupdater.com/pages/enter...dllversion.htm
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.