FormatConditions Bug
By Richard Rost
3 days ago
Error 7966 Conditional Formatting in VBA In this lesson, we will examine a specific Microsoft Access FormatConditions bug that can cause runtime error 7966 when VBA-created AcExpression conditional formatting rules reach the fourth item in the collection. We will discuss why FormatConditions(3) is the fourth rule, how whitespace in an expression can trigger the issue, how to reproduce and diagnose it, and practical workarounds such as removing optional spaces or creating rules manually in Design View. Kevin from Flushing, NY (a Silver Member) asks: I ran into a strange bug using FormatConditions in VBA. I can add several conditional formatting rules, but when my code tries to access the fourth rule, I get Runtime Error 7966. I discovered that removing the spaces from the expression, changing "1 = 1" to "1=1", makes the error go away. Is this an old Access bug that's come back, and are other people seeing it too? Recommended Courses
Keywords TechHelp Access, runtime error 7966, FormatConditions collection bug, AcExpression whitespace bug, conditional formatting VBA, FormatConditions(3), fourth conditional formatting rule, FormatConditions.Add, error 7966 workaround, VBA conditional formatting rules
More InformationTranscript Have you got conditional formatting rules that look perfectly fine, but Access suddenly throws a runtime error 7966 when you add one more? You may not have bad VBA at all. You may have stumbled into one of those weird old Access bugs.
Welcome to another TechHelp video brought to you by Access Learning Zone. I'm your instructor, Richard Rost.
Today we're going to look at a very specific error number 7966 problem involving the FormatConditions collection and VBA-created conditional formatting rules. In this case, things can work just fine, and then your code reaches the fourth rule, and the trigger is strange enough that you'd probably never guess what's going on on your own. I didn't.
We'll see how the problem was produced, look at a couple practical workarounds, and show you how to tell whether this is the particular 7966 issue you're dealing with or if it's something else entirely.
Today's question comes from Kevin in Flushing, New York, one of my Silver members. Kevin says, "I ran into a strange bug using format conditions in VBA. I can add several conditional formatting rules, but when my code tries to access the fourth rule, I get runtime error 7966. I also discovered that removing the spaces from the expression, changing one space equal space one to just one equals one, makes the error go away. Is this an old Access bug that's come back, and are other people seeing it too?"
Kevin, this is a good one, and nice detective work figuring out that removing the spaces makes the problem go away. That's certainly not something I would have thought to try first.
As it turns out, this is an old Access bug that apparently has come back from the dead. This is one of those bugs where you look at your code and you look at the conditions, and everything appears perfectly reasonable, and then Access says, "Nope, not doing that."
Now, this situation that we're focusing on happens when you use VBA to create conditional formatting rules using expression conditions, and then you try to work with those rules afterwards. Now, in this particular case, Access can fail when the code reaches the fourth conditional formatting rule.
But before we get into it, let's make sure we understand exactly what's failing because error 7966 can occur in other circumstances too. Here, we're talking about a specific reproducible FormatConditions bug.
Now, before we get into the error, some of you might not even realize that, yes, you can create and control conditional formatting with VBA. Normally, you set up conditional formatting manually in Design View using Conditional Formatting and the Rules Manager. And for most databases, that's perfectly fine.
But Access also gives us the FormatConditions collection in VBA. With code, you can create new conditional formatting rules, delete existing ones, change their colors and other properties, and build different rules dynamically while your database is running. Let's say that one user wants something to show up in red and the other one wants the same stuff in blue. Well, you can do that.
Now, this is definitely more advanced stuff, and I cover programming conditional formatting in my Access Developer 40 class. Now, granted, most Access users will probably never need to do this. But if you do use VBA to create or manipulate conditional formatting, that's where this particular error 7966 bug becomes important.
So, first, a little terminology, because this is important. A format condition is one conditional formatting rule attached to a control. For example, you might make an overdue balance turn red, a paid invoice turn green, or whatever. Format conditions, plural, is the condition collection. Think of a collection as the little container holding all of those rules for one control.
Now here's the part that catches people all the time in VBA. Collections are normally zero-based. That means the first collection is FormatConditions(0). The second one is FormatConditions(1), and so on. Just like combo box columns. The first combo box column is zero. Just like arrays, the first element in an array where you don't specify an upper and lower bound is zero.
So when you see this bug discussed as failing on FormatConditions(3), that doesn't mean the third rule. That means rule number four. Access didn't lose its ability to count. It's just a zero-based counter. It's programmer counting, which begins counting at zero because apparently programmers like keeping everyone slightly off balance.
And again, just as a side note, error 7966 isn't unique to this particular bug. You'll also get this error if you try to go beyond the maximum of 49 conditional formatting rules. Yeah, I know that's a lot, but I hit it one time. I was trying to make all kinds of different color gradients. Yeah, I got crazy, and I got this message. I'm like, "What?"
So, in that case, you'll get a message saying, "The format condition number you specified is greater than the number of format conditions," but that's a completely different cause. So today, we're specifically talking about the strange problem where the fourth condition can fail, even though you're nowhere near that limit.
Now, this particular problem has a recognizable pattern. First, you've got to have more than three conditional formatting rules. And second, those rules were added with VBA. And third, they use AcExpression, which means a condition is based on an expression that evaluates to true or false.
So then, when your code tries to access that fourth condition or a later one, Access might throw error 7966. The especially odd part is that the expression can be completely valid Access syntax. The issue isn't that spaces are illegal. Spaces in an expression are normally perfectly fine.
In this reported scenario, the presence of spaces appears to trigger buggy behavior while Access is handling the FormatConditions collection. So that is an observable trigger, not an explanation of Microsoft's internal code. And we know what reproduces it. We just don't know exactly what the little hamster wheel is slipping inside of Access.
So it's real easy to reproduce. Start with a form containing text box Name, Text1, or whatever. In the form's On Open event, you can delete any existing conditional formatting rules, then add, let's say, six rules in a loop. Each rule uses AcExpression and the simple expression, one equals one or something silly, but make sure you get spaces around that equal sign.
Now, that expression should always evaluate to true. That's not meant to be useful. It's just an example. We want to eliminate everything except the behavior of the conditional formatting itself.
So next, loop through all six formatting conditions, set the BackColor and ForeColor properties, and the rules are there. Then you can see Access successfully adds them, but in the reported tests, the code fails when I reach i = 3. And again, i = 3 means the fourth item in the collection.
And that detail is useful when troubleshooting your own database. So if your formatting code works fine, one, two, and three rules work fine, and then it suddenly breaks when you add another one, you're looking usually at a specific bug rather than a bad color value or a missing control name.
And again, the weird part is the trigger: 1 = 1. If you've got spaces around the equals, it fails. Without them, it works just fine. So you can consider this a workaround for a bug by removing the unnecessary whitespace in your expression.
And this is one reason why minimal example testing is so valuable. If you had a really complicated real-world expression here, it could take hours, going around brackets and field names and all kinds of stuff, form events, moon phases, whatever. Whenever you're trying to diagnose a problem, break it down and try a simple example. And that's always better than dealing with big, complicated expressions.
So what else should you do if you run into this? Well, again, remove the whitespace. One space equals one can become one equals one. If you've got something like balance is greater than zero, and you've got spaces around the greater-than symbol, remove those two.
And remember, don't have spaces in your field names, folks. Then you've got to have brackets around everything, and it becomes a pain. But that's just my personal opinion.
Now, don't go blindly removing every space from every expression in your application. Some expressions actually need separation between words. For example, logical operators like AND and OR need to remain readable with spaces around them. That keeps them syntactically correct. I love that word, syntactically.
Another practical workaround is to try creating conditional formatting manually in Design View using the exact same expressions. In these reported tests, the rules created through Access, the Design View interface, did not exhibit the same behavior. So once the rules exist, you might be able to modify their properties with VBA as needed.
And also, I've had problems with conditional formatting too, usually after Access updates. So Access updates can fix old bugs, and they can also reintroduce old bugs. So sometimes stuff that they fix then ends up coming back in a future release. So they have a habit of moving the furniture around when you're not looking sometimes.
But yeah, I've got to give Kevin credit for posting this in the forums and reproducing the behavior. And of course, Donald Blackwell independently reproduced the problem using Access version 2609. I investigated it a little more and found that it was reported to Microsoft as far back as 2023.
So we're not discovering a completely new kind of bug here, but it is still something that's coming up. And I did some searching, and a bunch of other people have reported this so far in different online forums. So it's not just us.
Now, I did bring this to the attention of the Access team. So it's on their radar, and hopefully they're looking into it, and we'll have a fix very soon.
Now, if you encounter the error 7966 in your own database, don't immediately start rewriting your entire form and pulling your VBA code apart. Diagnose it like a developer.
First, determine exactly which collection item causes the failure. Is it FormatConditions(3), meaning the fourth rule, or is it something completely different in a different line of code? Then check how the rules got there. Did you add them manually, or did you use FormatConditions.Add in your VBA? Third, look for expression strings created with AcExpression. Then try to simplify the expression and see whether removing optional spaces changes the result. And if you can, try testing on a different machine with a different build. See if that comes up.
And if you've still got a problem, let us know. Post it in the forums or in the comments down below. Remember, a good bug report is not just, "Access crashed." Tell us what you did, what you checked, what you got, what you found out. Just like Kevin did here. Reproduce the steps and let us know what you did.
So, to wrap it up, FormatConditions is a collection of conditional formatting rules for a control, and FormatConditions(3) means the fourth rule because VBA starts counting at zero. The reported error 7966 problem occurs under a specific set of conditions: multiple rules, added with VBA, using AcExpression with whitespace in the expression text.
It's not proof that every 7966 error has the same cause, but this one is pretty reproducible. Thanks again to Kevin Yip for reproducing this bug and posting it in the forums, and for the workaround, and to Donald Blackwell, who independently confirmed it.
And hopefully, if you found this video and you're having this problem, hopefully this one saves you from spending an afternoon arguing with a space character in your VBA code. Those little guys can be surprisingly powerful.
So there you go. That's your TechHelp video for today. I hope you learned something, and I hope this helps someone out. Live long and prosper, my friends. Intro In this lesson, we will examine a specific Microsoft Access FormatConditions bug that can cause runtime error 7966 when VBA-created AcExpression conditional formatting rules reach the fourth item in the collection. We will discuss why FormatConditions(3) is the fourth rule, how whitespace in an expression can trigger the issue, how to reproduce and diagnose it, and practical workarounds such as removing optional spaces or creating rules manually in Design View. Quiz Q1. What is a FormatCondition in Microsoft Access?
A. A single conditional formatting rule attached to a control
B. A form property that controls record filtering
C. A VBA module that stores color constants
D. A table relationship used for validation
Q2. What does the FormatConditions collection represent?
A. All forms in the database
B. The collection of conditional formatting rules for one control
C. All controls on a form
D. A list of VBA error messages
Q3. What does FormatConditions(3) refer to?
A. The third conditional formatting rule
B. The fourth conditional formatting rule
C. The first conditional formatting rule
D. The maximum number of allowed rules
Q4. Why does FormatConditions(3) refer to the fourth rule?
A. Access reserves the first three rules for built-in formatting
B. FormatConditions collections are zero-based
C. Conditional formatting rules are numbered by color
D. VBA automatically skips expression conditions
Q5. Which situation is associated with the specific runtime error 7966 bug discussed in the video?
A. Using more than three manually created formatting rules
B. Using VBA to add multiple AcExpression formatting rules
C. Applying conditional formatting to a report instead of a form
D. Setting a control's BackColor property directly
Q6. In the reported bug, when does the failure commonly occur?
A. When Access adds the first rule
B. When code accesses the fourth rule
C. When a form is saved in Design View
D. When the database is compacted
Q7. What does AcExpression mean when creating a format condition?
A. The condition is based on an expression that evaluates to True or False
B. The condition applies only to text fields
C. The rule is created manually in Design View
D. The rule uses a built-in color gradient
Q8. Which expression detail was found to trigger the buggy behavior in the reported example?
A. Using brackets around a field name
B. Using spaces around an operator, such as "1 = 1"
C. Using a number in an expression
D. Using the equal sign in any expression
Q9. What is one practical workaround for this specific FormatConditions bug?
A. Remove optional whitespace around operators where doing so remains valid syntax
B. Convert all expressions to SQL queries
C. Add at least 49 formatting rules before accessing them
D. Replace all conditional formatting with validation rules
Q10. Why should you not blindly remove every space from every expression?
A. Access requires every expression to contain at least one space
B. Some operators and keywords, such as AND and OR, need separation to remain valid and readable
C. Removing spaces always makes expressions run slower
D. Spaces are required for numeric comparisons
Q11. What is another workaround to try if VBA-created rules cause this issue?
A. Create the conditional formatting rules manually in Design View
B. Move the form controls into a table
C. Change all text boxes into combo boxes
D. Delete the form's record source
Q12. Why is it important to distinguish this bug from other error 7966 situations?
A. Error 7966 only occurs when a database is corrupted
B. Error 7966 can have other causes, including exceeding the maximum number of formatting rules
C. Error 7966 always means a control name is misspelled
D. Error 7966 only applies to reports
Q13. What is a good first troubleshooting step when encountering error 7966 with conditional formatting?
A. Rewrite the entire form immediately
B. Determine the exact collection item and line of code that fails
C. Delete all VBA modules from the database
D. Change every color property to black
Q14. Why is creating a minimal reproducible example helpful when diagnosing this issue?
A. It helps isolate the formatting behavior from complex expressions and unrelated form logic
B. It permanently repairs Access bugs
C. It increases the maximum number of formatting rules
D. It prevents users from changing form colors
Q15. Which statement best describes the relationship between this bug and error 7966?
A. Every error 7966 is caused by whitespace in an expression
B. The bug is one specific reproducible cause of error 7966, but other causes exist
C. Error 7966 only occurs with manually created rules
D. Error 7966 means an AcExpression condition is always invalid
Answers: 1-A; 2-B; 3-B; 4-B; 5-B; 6-B; 7-A; 8-B; 9-A; 10-B; 11-A; 12-B; 13-B; 14-A; 15-B
DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks. Summary Today's video from Access Learning Zone covers a specific Microsoft Access bug involving VBA-created conditional formatting rules and runtime error 7966.
I want to focus on a situation where your conditional formatting code appears to be correct, several rules are created successfully, and then Access suddenly fails when you try to work with the fourth rule. In this case, the problem may not be your VBA code at all. It may be an old Access bug that has reappeared in newer versions of the software.
Conditional formatting is normally configured manually in a form's Design View using the Conditional Formatting Rules Manager. For most databases, that is all you need. However, Access also provides the FormatConditions collection in VBA, which allows you to create, delete, and modify conditional formatting rules programmatically.
This can be useful when rules need to be generated dynamically. For example, different users may need different formatting colors or conditions based on their preferences, permissions, or other settings. You can use VBA to add the appropriate rules while the database is running.
This is more advanced Access development material, and I cover VBA-controlled conditional formatting in my Access Developer 40 class. Most users will never need to create conditional formatting rules with VBA, but if you do, this particular error is worth understanding.
A format condition is one conditional formatting rule attached to a control. For example, you might create one rule that makes overdue balances appear in red and another that makes paid invoices appear in green. The FormatConditions collection is the collection that holds all of those rules for a specific control.
One important detail is that the FormatConditions collection is zero-based. That means the first rule is FormatConditions(0), the second rule is FormatConditions(1), and so on. Therefore, FormatConditions(3) refers to the fourth rule in the collection, not the third one.
This is similar to combo box columns, which are also zero-based. The first combo box column is column zero. Arrays frequently begin at zero as well. It is simply the way many programming collections are numbered.
Error 7966 is not unique to this particular bug. You can also receive error 7966 if you exceed the maximum number of conditional formatting rules. Access supports up to 49 format conditions for a control. If you try to add more than that, Access can raise an error indicating that the format condition number specified is greater than the available number of format conditions.
That is a different situation from the bug discussed here. In this case, the error occurs when you are nowhere near the 49-rule limit.
The bug follows a fairly recognizable pattern. First, there must be more than three conditional formatting rules. Second, the rules must have been added using VBA rather than manually through the Access interface. Third, the rules must use AcExpression conditions, meaning that the conditional formatting rule is based on an expression that evaluates to True or False.
Under these circumstances, Access may throw runtime error 7966 when VBA tries to access the fourth format condition or a later condition.
The oddest part of this issue is that the expression itself can be perfectly valid. In the reported example, a simple always-true expression such as 1 = 1 can trigger the bug when spaces appear around the equal sign.
The spaces are not normally invalid. Access expressions commonly contain spaces, and there is nothing inherently wrong with writing an expression with spaces around an operator. However, under this particular set of circumstances, whitespace in the expression appears to trigger a bug in Access while it is handling the FormatConditions collection.
This is important to understand. The presence of spaces is an observable trigger, not necessarily an explanation of the internal Access problem. We can identify the behavior that reproduces the error, but we do not know exactly what is happening internally within Access.
A simple test can reproduce the problem. Start with a form containing a text box control. When the form opens, remove any existing conditional formatting rules from that control. Then use VBA to add several rules, such as six expression-based rules. Each rule can use a simple expression that always evaluates to True.
The purpose is not to create useful formatting. The purpose is to isolate the behavior and eliminate other possible causes, such as complex field references, form controls, functions, or record values.
After adding the rules, loop through the FormatConditions collection and attempt to set properties such as BackColor and ForeColor for each rule. In the reported tests, Access successfully creates the rules, but raises runtime error 7966 when the code reaches item 3, which is the fourth rule.
This is useful when diagnosing your own database. If your formatting logic works for one, two, or three rules, but fails as soon as you add a fourth rule, you may be dealing with this specific Access bug rather than a bad color value, an invalid control name, or a VBA syntax problem.
The most practical workaround is to remove unnecessary spaces from the expression text. For example, if you have an expression such as 1 = 1, changing it to 1=1 may avoid the error. Likewise, an expression such as Balance > 0 may work better as Balance>0 if the spaces around the comparison operator are optional.
Do not remove every space from every expression without thinking about it first. Some expressions need spaces to remain valid and readable. Logical operators such as AND and OR require separation from the surrounding words and values. You should only remove whitespace where it is clearly optional, such as directly around mathematical or comparison operators.
Also, avoid using spaces in field names whenever possible. Field names with spaces require brackets and make expressions more difficult to read and maintain. A field named BalanceDue is generally easier to work with than one named Balance Due.
Another workaround is to create the conditional formatting rules manually in Design View using the same expressions. In reported testing, rules created through the Access user interface did not exhibit the same failure. Once the rules exist, you may still be able to modify some of their properties with VBA as necessary.
This may be especially useful if your rules are mostly static and only need occasional programmatic changes. You can define the rules manually in the form design and then use VBA only to adjust colors or related properties.
Access updates can sometimes fix old bugs, but they can also reintroduce bugs that appeared to have been resolved. Conditional formatting has had its share of unusual behavior over the years, particularly after Office and Access updates. This particular problem was reported to Microsoft years ago, and it has been independently reproduced in newer Access builds.
If you encounter runtime error 7966, do not immediately assume that your entire form or VBA procedure needs to be rewritten. Treat it like a developer and isolate the cause.
First, identify the exact line that fails. Determine whether the error occurs specifically when accessing FormatConditions(3), which is the fourth conditional formatting rule, or whether it occurs somewhere else.
Second, determine how the rules were created. Were they added manually through the Conditional Formatting Rules Manager, or were they created using the FormatConditions.Add method in VBA?
Third, check whether the rules use AcExpression conditions. If they do, simplify the expression as much as possible. Try using a basic True or False expression to see whether the behavior can be reproduced with minimal code and minimal conditions.
Fourth, test whether removing optional whitespace around operators changes the result. If an expression works without spaces but fails with spaces, that is a strong indication that you are encountering this specific Access bug.
Finally, if possible, test the same database on another computer or with a different version of Access. Since this problem may be version-dependent, behavior can vary between Office builds.
A good bug report should include more than a statement that Access crashed or generated an error. Explain what you did, where the error occurred, how the rules were created, what expression was used, and what changes affected the result. A minimal reproducible example is one of the most useful things you can provide when troubleshooting a problem or reporting it to Microsoft.
To summarize, FormatConditions is the collection of conditional formatting rules attached to a control. FormatConditions(3) refers to the fourth rule because the collection is zero-based.
The runtime error 7966 issue discussed here appears under a specific combination of conditions: multiple format rules, created with VBA, using AcExpression, with whitespace in the expression text. This does not mean that every error 7966 is caused by this bug, but it is a repeatable problem that can save you a lot of troubleshooting time if you recognize the pattern.
If your fourth VBA-created conditional formatting rule suddenly fails, try simplifying the expression and removing optional spaces around operators. It may be enough to work around the bug until Microsoft provides a permanent fix.
You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends. Topic List Access FormatConditions collection basics
Zero-based FormatConditions indexing
Runtime error 7966 with conditional formatting
Reproducing the fourth format condition bug
AcExpression rules created with VBA
Whitespace trigger in expression conditions
Removing optional spaces as a workaround
Creating conditional formatting rules in Design View
Diagnosing FormatConditions error 7966 Article Microsoft Access lets you create and manage conditional formatting rules through VBA by using a control's FormatConditions collection. This can be useful when formatting needs to be created dynamically at runtime, such as when different users need different color schemes or when the conditions depend on settings in the database.
A format condition is one conditional formatting rule attached to a control. The FormatConditions collection is the group of all such rules for that control. For example, a text box might have one rule that turns it red when a balance is overdue and another that turns it green when an invoice is paid.
One important detail is that the FormatConditions collection is zero-based. The first rule is FormatConditions(0), the second is FormatConditions(1), and the fourth is FormatConditions(3). This matters when troubleshooting because an error involving item 3 is actually occurring on the fourth formatting rule.
There is a specific Microsoft Access bug that can produce runtime error 7966 when working with conditional formatting rules created through VBA. The problem is not necessarily bad VBA, an invalid color value, or an incorrect control name. Under certain conditions, Access can successfully create several rules but fail when code later attempts to access or modify the fourth rule or a later rule.
The issue has a recognizable pattern. The rules are added through VBA rather than manually in Design View. They use expression-based conditions, meaning the condition type is AcExpression. There are more than three rules. Then, when the code accesses the fourth rule in the collection, Access may raise error 7966.
The especially strange part is that optional whitespace in the expression can trigger the problem. An expression such as "1 = 1" is valid Access syntax and should work normally. However, in this particular bug, Access may fail when expression-based conditional formatting rules contain spaces around operators. Changing the same expression to "1=1" can make the problem disappear.
This does not mean spaces are generally invalid in Access expressions. They are normally allowed and often improve readability. It also does not mean every instance of error 7966 has this cause. Error 7966 can occur for other reasons, including attempting to refer to a format condition that does not exist or exceeding the limit of conditional formatting rules. Access allows up to 49 conditional formatting rules for a control, and trying to go beyond that limit is a separate issue.
If you encounter error 7966 while working with FormatConditions, first identify the exact line and collection item causing the failure. If the error occurs when accessing FormatConditions(3), that means the fourth rule. If the first three rules work consistently and the problem begins with the fourth, this particular bug is worth investigating.
Next, determine how the rules were created. If they were added manually through the Conditional Formatting Rules Manager, the problem may have a different cause. If they were created through VBA using expression conditions, simplify the expression as much as possible. Test with a harmless expression that always evaluates as true. If that works without spaces but fails with spaces around an operator, you have likely found the issue.
The simplest workaround is to remove optional whitespace around operators in the expression text. For example, an expression like "[Balance] > 0" may be changed to "[Balance]>0" if doing so does not make the expression unclear or invalid. Do not remove every space blindly. Some expressions require spaces between words, especially logical operators such as AND and OR. The goal is to remove only optional whitespace around symbols such as equals signs, greater-than signs, and less-than signs.
Another workaround is to create the conditional formatting rules manually in Design View. In reported cases, rules created through the Access interface did not exhibit the same behavior. Once the rules are already present on the control, VBA may still be able to modify properties such as colors and fonts without triggering the error.
When diagnosing problems like this, reduce the situation to the smallest possible test. Use one form, one control, a few simple expression rules, and a basic attempt to access each rule afterward. This makes it much easier to separate an Access bug from problems involving field names, form events, complex expressions, missing controls, or other database logic.
If you need to report the problem, include the exact expression text, the number of rules being created, whether the rules were added through VBA or manually, and which FormatConditions collection item causes the error. A reproducible test is much more useful than simply reporting that Access crashed or displayed an error.
In short, a failure on FormatConditions(3) means Access is failing on the fourth conditional formatting rule. If the rules were created through VBA, use AcExpression conditions, and contain optional spaces around operators, runtime error 7966 may be caused by a known Access bug rather than by a mistake in your code. Simplifying the expression, removing optional spaces, or creating the rules manually are practical ways to work around it. Primary Topics Access runtime error 7966, FormatConditions collection, VBA-created conditional formatting, AcExpression rules, fourth conditional formatting rule failure, whitespace workaround, conditional formatting troubleshooting Secondary Topics zero-based collection indexing, conditional formatting rule limits, Design View versus VBA-created rules, minimal reproducible testing, bug reporting |
