 | |
#1
 
| |||
| |||
|
ForeColor <> Expected? -
01-07-2011
, 09:40 AM
#2
| |||
| |||
|
|
Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee |
Programmatically setting .FormatConditions and then deleting same
somehow leaves things as if .FormatConditions were still in
place.... and I had made an unfortunate choice of shades of blue
against the grey background....
Times like this, I *really* wish I could delete NG posts.... -)
--
PeteCresswell
#3
| |||
| |||
|
|
Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) |
Actually no. I'm glad you psoted. This is useful because the
solution was not obvious.
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/
#4
| |||
| |||
|
|
On Fri, 07 Jan 2011 11:03:51 -0500, "(PeteCresswell)" x@y.Invalid> wrote: Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) Hehehe. Actually no. I'm glad you psoted. This is useful because the solution was not obvious. |
experience the excruciate process of wracking my brain trying to
remember what caused the problem, and doing dozens of Google Groups
searches trying to find it, to no avail.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#5
| |||
| |||
|
|
Times like this, I *really* wish I could delete NG posts.... -) Hehehe. Actually no. I'm glad you psoted. This is useful because the solution was not obvious. Yes, and if I ever encounter the same thing, I'll be able to experience the excruciate process of wracking my brain trying to remember what caused the problem, and doing dozens of Google Groups searches trying to find it, to no avail. |
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/
#6
| |||
| |||
|
|
Per (PeteCresswell): Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) |
I do have one little tidbit of information about using code
to set/change/delete a FormatCondition. Doing that kind of
thing in code does not mark the form as dirty, so closing
the form does not automatically save the change. I found
that if the CF code is followed by a line that makes any
innocuous change (e.g. Me.text1.Left = Me.text1.Left) then
Access will recognize that the form has been changed and
save it.
--
Marsh
#7
| |||
| |||
|
|
Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) Glad you did post it. I do have one little tidbit of information about using code to set/change/delete a FormatCondition. Doing that kind of thing in code does not mark the form as dirty, so closing the form does not automatically save the change. I found that if the CF code is followed by a line that makes any innocuous change (e.g. Me.text1.Left = Me.text1.Left) then Access will recognize that the form has been changed and save it. |
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/
#8
| |||
| |||
|
|
(PeteCresswell) wrote: Per (PeteCresswell): Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) Glad you did post it. I do have one little tidbit of information about using code to set/change/delete a FormatCondition. Doing that kind of thing in code does not mark the form as dirty, so closing the form does not automatically save the change. I found that if the CF code is followed by a line that makes any innocuous change (e.g. Me.text1.Left = Me.text1.Left) then Access will recognize that the form has been changed and save it. |
a data change? There is no way to detect, so far as I know, if a
design change is unsaved (Me.Dirty is only about data). Setting a
property at runtime should not, in my opinion, cause a form's design
to be marked for the need to be changed. If it did, it would mean
users got prompts all the time, and that would be terrible.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#9
| |||
| |||
|
|
Marshall Barton <marshbarton (AT) wowway (DOT) com> wrote in news:mqrfi6d0tahs6m1tmplr4f4pcqs980g4b0 (AT) 4ax (DOT) com: (PeteCresswell) wrote: Per (PeteCresswell): Can anybody think of anything that might cause rendering in grey even though .ForeColor = 0? viz: http://tinyurl.com/252ecee Got it. Programmatically setting .FormatConditions and then deleting same somehow leaves things as if .FormatConditions were still in place.... and I had made an unfortunate choice of shades of blue against the grey background.... Times like this, I *really* wish I could delete NG posts.... -) Glad you did post it. I do have one little tidbit of information about using code to set/change/delete a FormatCondition. Doing that kind of thing in code does not mark the form as dirty, so closing the form does not automatically save the change. I found that if the CF code is followed by a line that makes any innocuous change (e.g. Me.text1.Left = Me.text1.Left) then Access will recognize that the form has been changed and save it. I'm really confused. Aren't we talking about a design change versus a data change? There is no way to detect, so far as I know, if a design change is unsaved (Me.Dirty is only about data). Setting a property at runtime should not, in my opinion, cause a form's design to be marked for the need to be changed. If it did, it would mean users got prompts all the time, and that would be terrible. |
Sorry, David, my post really was confusing. I was trying to
describe a situation where the form was opened in design
view by:
DoCmd.OpenForm "theForm", acDesign
then changing *only* CF properties does not mark Access'
internal "dirty" flag (not the form property) that indicates
the form's design has been changed. When the form is then
closed by using:
DoCmd.Close "theform", acSaveYes
Access does NOT save the form's design because it doesn't
realize that the form's design was changed.
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.
--
Marsh
#10
| |||
| |||
|
|
I do have one little tidbit of information about using code to set/change/delete a FormatCondition. Doing that kind of thing in code does not mark the form as dirty, so closing the form does not automatically save the change. I found that if the CF code is followed by a line that makes any innocuous change (e.g. Me.text1.Left = Me.text1.Left) then Access will recognize that the form has been changed and save it. I'm really confused. Aren't we talking about a design change versus a data change? There is no way to detect, so far as I know, if a design change is unsaved (Me.Dirty is only about data). Setting a property at runtime should not, in my opinion, cause a form's design to be marked for the need to be changed. If it did, it would mean users got prompts all the time, and that would be terrible. Sorry, David, my post really was confusing. I was trying to describe a situation where the form was opened in design view by: DoCmd.OpenForm "theForm", acDesign then changing *only* CF properties does not mark Access' internal "dirty" flag (not the form property) that indicates the form's design has been changed. When the form is then closed by using: DoCmd.Close "theform", acSaveYes Access does NOT save the form's design because it doesn't realize that the form's design was changed. 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. |
still present. IMNSHO this is a bug and not a feature.
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.