Not Enough Conditions
Edward Backstrom
table. There is a dropbox that contains a value from 0 to 7 that should be
used to color code the record.
Conditional Formatting a pseudo background will not work as there are too
many conditions (8 total). I have also tried to adapt the code from
www.lebans.com/formatbycriteria.htm but have been unsuccessful. We are using
A2K and A2K3 on our machines.
Any tips/suggestions are appreciated.
TC
their head, IMHO. We can all understand red/yellow/green, or somesuch,
but once it becomes red/orange/yellow/green/blue/indigo/violet, it's
just too hard to remember what each colour is for. It might /look/
good, but is it of a demonstrable, functional benefit?
Could you just display a status number or code against each record?
HTH,
TC [MVP Access]
TC
TC
Marshall Barton
I certainly agree with TC about too many colors making the
UI confusing and probably difficult to peruse. There is
also the issue of different kinds of color blindness seeing
the records in different ways, rendering some color's
significance meaningless.
With all that in mind, if you persist in this direction, you
still have to be careful that the data in the form is
readable by keeping the backcolor of each text box (and
their labels?) at a high contrast to the text in the
controls. This usually means that the part of the records
that is colored is the section background behind the
controls. If that's where you end up, then you can do this
by placing two text boxes of the same size as the detail
section behind all the other controls. Those two text boxes
can then use Conditional Formatting along with a special
font (see http://www.mvps.org/access/forms/frm0055.htm)
to display four colors each or be transparent depending on
their control source expression. The control source
expressions would be like:
=Iff(combo <= 3,"AAAAAAA", " ")
=Iff(combo >= 4,"AAAAAAA", " ")
The CF Expression Is: option would then be:
default with ForeColor for color0
[combo] = 1 with ForeColor for color1
[combo] = 2 with ForeColor for color2
[combo] = 3 with ForeColor for color3
similarly for colors 4 through 7 in the second combo box.
After all the CF settings are correct, then set the two text
boxes BackStyle to Transparent.
--
Marsh
MVP [MS Access]
Edward Backstrom
The color coding is used to quickly identify a 'ticket status' such as Open,
Pending, In Progress, and etc. As far as persons with disabilities, that is
why there is the combobox that textually reflects the status. The color
scheme uses light colors to provide contrast with the black text. With that
said, I tried what you suggested and it works with one caveat, the
background flashes uncontrollably. Although the status combo addresses the
issue of color blindness, I do not wish to send the user into a seizure.
Thank you for your assistance so far and I greatly appreciate any further
help.
"Marshall Barton" <marsh...@wowway.com> wrote in message
news:8avcs1hrimrcmir3r...@4ax.com...
Marshall Barton
someone has reported that effect, I have never been able to
reproduce it. If you would strip down a copy of your mdb to
just the form and some sample data that still exhibits the
problem, Compact and ZIP it to a reasonable size and then
send it to me, I would appreciate a chance to analyze it.
If I can reproduce it here, I can try to figure out what's
causing it or send it on to MS to see if they can explain
it.
--
Marsh
MVP [MS Access]
Edward Backstrom wrote:
>The color coding is used to quickly identify a 'ticket status' such as Open,
>Pending, In Progress, and etc. As far as persons with disabilities, that is
>why there is the combobox that textually reflects the status. The color
>scheme uses light colors to provide contrast with the black text. With that
>said, I tried what you suggested and it works with one caveat, the
>background flashes uncontrollably. Although the status combo addresses the
>issue of color blindness, I do not wish to send the user into a seizure.
>Thank you for your assistance so far and I greatly appreciate any further
>help.
>
>
>"Marshall Barton" wrote
Edward Backstrom
This is interesting. I recreated the fields thinking I may have omitted
something. The field displays #Name? instead of the block characters and
still flashes. When I select another non-access window however, the
flashing stops. I assume the #Name? is query related although the fields
are named differently and did not change from the first test that worked.
The subform is populated by a query and is not linked to a master/child
field on the main form. I have taken over this database from someone else
and it has been an interesting project. I will work on sending you a
stripped version but maybe this additional information will be of benefit
before then. Please feel free to email me if you would like to move this
discussion from the newsgroup. Thank you again.
"Marshall Barton" <marsh...@wowway.com> wrote in message
news:gn8es1p2ndabjtn5o...@4ax.com...
Marshall Barton
that you mean "controls". In any case, #Name usually means
that you mispelled a name, i.e. using a name that Access can
not resolve in the current context. So, at this point, I
can only assume that you've made a mistake somewhere. The
fact that you can see the #Name instead of the block
characters means that you did not specify the Labox font for
the control.
Selecting another application will probably dramatically
slow the flashing just because Access is not the foreground
task and does not have any real significance.
--
Marsh
MVP [MS Access]
Edward Backstrom wrote:
>This is interesting. I recreated the fields thinking I may have omitted
>something. The field displays #Name? instead of the block characters and
>still flashes. When I select another non-access window however, the
>flashing stops. I assume the #Name? is query related although the fields
>are named differently and did not change from the first test that worked.
>The subform is populated by a query and is not linked to a master/child
>field on the main form. I have taken over this database from someone else
>and it has been an interesting project. I will work on sending you a
>stripped version but maybe this additional information will be of benefit
>before then. Please feel free to email me if you would like to move this
>discussion from the newsgroup. Thank you again.
>
>"Marshall Barton" wrote
Edward Backstrom
We live, we learn. When recreating the controls, I used "iff" instead of
"iif" in the control source, hence the #Name? issue. The irony is that I
may not have caught that right away if the font was changed. I have
corrected and all works well (again). I was doing testing on our computers
it appears the flashing issue is present on version 11.5614.6360 (the
machine I tested on first). This machine is 11.6355.6360 SP1 and does not
have this problem. Thank you greatly for your assistance.
"Marshall Barton" <marsh...@wowway.com> wrote in message
news:pivfs1hcgvmk8ivdd...@4ax.com...
Marshall Barton
Including the two versions I tested it on, we can start a
list.
No flashing problem:
10.6501.6626 (SP3)
11.6566.6568 (SP2)
11.6355.6360 (SP1)
Exhibits flashing problem:
11.5614.6360
I guess that your solution is now obvious and easy to do
(barring administrator hangups). A very nice job tracking
it down and thanks for posting your results so others can
Google for the answer.
If anyone else runs into this issue, I hope they will add to
our initial list of versions.
--
Marsh
MVP [MS Access]
Edward Backstrom wrote:
>We live, we learn. When recreating the controls, I used "iff" instead of
>"iif" in the control source, hence the #Name? issue. The irony is that I
>may not have caught that right away if the font was changed. I have
>corrected and all works well (again). I was doing testing on our computers
>it appears the flashing issue is present on version 11.5614.6360 (the
>machine I tested on first). This machine is 11.6355.6360 SP1 and does not
>have this problem. Thank you greatly for your assistance.
>
>"Marshall Barton" wrote