| T O P I C R E V I E W |
| kennyl |
Posted - Dec 09 2009 : 02:00:04 AM
Example:
#define INVALIDATE_RECT(_rect) InvalidateRect(&_rect, FALSE)
Problem 1:
References highlighting does not work inside macro block.
e.g. try to place cursor on _rect and no coloring for it
Problem 2:
Matching brace {} and () are not highlighted.
Regards! |
| 8 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Feb 01 2010 : 2:00:18 PM
To be honest a highlight in macros case was closed in the past with by design because of the side-effects which we have discussed.
Despite this, I have put in a feature request for re-consideration with the fresh ideas to see what developers make of it:
case=39035 |
| Tanalia |
Posted - Jan 28 2010 : 5:26:08 PM
Working with a lot of legacy code (and programmers  ), originally in C, and often it's still easier to work with the existing macro than to convert it to a more modern form -- many (large!) "evil" macros that depend on non-arguments  -- so just wondering if there's a relatively straightforward way to get some sort of match checking within macros.
If I interpret your last suggestion correctly, the idea would be to show matches in macros, but not flag the mismatches. Even this would be a big help, as little, if any, of the code I work on has mismatches on purpose. |
| accord |
Posted - Jan 28 2010 : 1:20:37 PM
Generally, we try to avoid using too much settings in our options dialog. I have a suggestion which would make things easier: what about turning on brace maches, but keep mismatches off? It would make everyone a little happier, because we could turn it on by default.
Out of interest, just a personal notice: don't you use too much macro if you need this feature?  I try to use inline or template functions where it is possible. |
| Tanalia |
Posted - Jan 27 2010 : 8:31:40 PM
Ok. Personally, I wouldn't worry trying to interpret whether the braces "really" match (due to the definition of BEGIN) or not, just try to match those specifically within the macro.
Maybe:
1) a new checkbox in the Advanced/Display settings to activate matching within macros (default off to match current behavior), and document the limitations
2)the new color setting for in-macro mismatches, defaulted to the same as the normal mismatch so it's not easily ignored, unless the user wants to tone it down |
| accord |
Posted - Jan 09 2010 : 3:17:04 PM
Interesting idea. However, there are more problems with preprocessor macros:
#define BEGIN {
#define SOMEMACRO { BEGIN int Apple; |}}
Here, VA would indicate brace mismatching. (| represents the caret)
The solution may be to take the brace in "BEGIN" into account.
But this is a simplified example, and only a taste of what can be done with macros. Even more depth, content that depends on which file was the define included into, etc. We limit the complexity of macro parsing in some way to prevent slowdowns which would occur in extremely complex cases. If VA used this new, paler warning color, maybe it would make users to skip these indications as an "erratic" behavior which is sometimes wrong. |
| Tanalia |
Posted - Jan 08 2010 : 4:14:43 PM
While I understand that braces and parens need not be balanced in a #define, it would still be useful to show matches/mismatches within the scope of the definition (nesting considered separately from the surrounding code).
For most uses this would be beneficial; for cases like the Begin and End being mapped onto braces, it would flag that something [a bit] unusual is being done (and maybe add a new coloring option for preprocessor delimiter mismatches, so they are flagged but don't jump out as strongly as normal code mismatches). |
| kennyl |
Posted - Dec 11 2009 : 02:16:20 AM
Thanks for clarifying!
Regards! |
| accord |
Posted - Dec 09 2009 : 2:54:24 PM
1. I am seeing the same effect here:
case=36688
2. This is by design: it is not necessary for a define to have balanced braces and parens. For example, these type of defines are common:
#define BeginMessageMap foo blah[] = {
#define EndMessageMap }; |
