Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Bracket-highlighting loses effect for #define

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
chjfth Posted - Oct 21 2006 : 09:36:16 AM
For example, in the following #define directive:


#define GetEleQuan_i(array) ((int)GetEleQuan(array))

Bracket-highlighting does not take effect, however, Bracket-highlighting works in other context, e.g. in a function body, or in parameter list of a function declaration.

VAX version info:
VA_X.dll file version 10.3.1539.0 built 2006.10.12
Licensed to:
<hidden>
VAOpsWin.dll version 1.3.3.6
VATE.dll version 1.0.5.8
MSDev.exe version 6.0.9782.2
Devshl.dll version 6.0.9782.0
Devedit.pkg version 6.0.9782.0
Font: +?+?+?+? 16(Pixels)
Comctl32.dll version 5.81.4916.400
Windows 2000 5.0 Build 2195 Service Pack 4
Single processor

Platform: Custom
Stable Includes:
E:\\MicrosoftSDK\\include;
C:\\MicrosoftVisualStudio\\VC98\\INCLUDE;
C:\\MicrosoftVisualStudio\\VC98\\MFC\\INCLUDE;
C:\\MicrosoftVisualStudio\\VC98\\ATL\\INCLUDE;

Library Includes:
C:\\MicrosoftVisualStudio\\VC98\\MFC\\SRC;
C:\\MicrosoftVisualStudio\\VC98\\MFC\\INCLUDE;
C:\\MicrosoftVisualStudio\\VC98\\ATL\\INCLUDE;
C:\\MicrosoftVisualStudio\\VC98\\CRT\\SRC;

Other Includes:
g:\\w\\CommonLib\\common-include;
g:\\w\\CommonLib\\common-include\\mswin;


7   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Oct 24 2006 : 1:45:46 PM
Your logic is sound. Personally I do not know what lead to this particular design decision, but there are a lot of edge cases where VA runs into problems. Somewhere along the line we have to prioritize them, and deciding to leave some things undone for now helps.

One factor that may be relevant is that VA does not try to be to clever evaluating macro's in code.
chjfth Posted - Oct 24 2006 : 01:08:05 AM
Thanks again for replying. Anyway, I don't think enabling bracket highlighting causes harm when a macro definition have unpaired brackets. You just highlight as many matching brackets as there are, and leave the unmatched ones in weird user-chosen colors.

Take BEGIN_MESSAGE_MAP and END_MESSAGE_MAP for instance(blue for matching ones, red for unmatched ones):


#define BEGIN_MESSAGE_MAP(theClass, baseClass) \	const AFX_MSGMAP* theClass::GetMessageMap() const \		{ return &theClass::messageMap; } \	AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \	{ &baseClass::messageMap, &theClass::_messageEntries[0] }; \	AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \	{ \

#define END_MESSAGE_MAP() \		{0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \	}; \


By the way, if there is a unmatched opening bracket in a macro definition, its effect should be limited only to the scope of that macro, e.g. in the above example, the red curly bracket in BEGIN_MESSAGE_MAP should NOT be paired with the red curly bracket in END_MESSAGE_MAP.

Is there anything wrong with my idea, or any subverting conditions that I have missed?
feline Posted - Oct 23 2006 : 1:32:12 PM
chjfth this is a very good example of this effect, I do agree with jpizzi, although I have seen worse *rolls eyes*

Unfortunately a significant number of macro's make use of unpaired brackets. BEGIN_MESSAGE_MAP in afxwin.h is an example I run across now and then, and I have seen people use one macro to start a namespace and a second macro to end it, both of which use unpaired brackets.

I sometimes feel that macro's are one big edge case.
jpizzi Posted - Oct 22 2006 : 11:45:55 PM
Now that macro fits my definition of write-only code!
chjfth Posted - Oct 22 2006 : 12:46:01 AM

Hmm, may be it's not a good design, since programmers sometimes have to read or write some very long #define directives which consist quite a lot of brackets, e.g. in Winsock2.h:


#define FD_CLR(fd, set) do { \    u_int __i; \    for (__i = 0; __i < ((fd_set FAR *)(set))->fd_count ; __i++) { \        if (((fd_set FAR *)(set))->fd_array[__i] == fd) { \            while (__i < ((fd_set FAR *)(set))->fd_count-1) { \                ((fd_set FAR *)(set))->fd_array[__i] = \                    ((fd_set FAR *)(set))->fd_array[__i+1]; \                __i++; \            } \            ((fd_set FAR *)(set))->fd_count--; \            break; \        } \    } \} while(0)


Now, do you think it helpful with bracket-matching-highlighting on for the above #define ?

After all, using Ctrl-] is far more inconvenient than visual highlighting, isn't it?
support Posted - Oct 21 2006 : 1:38:32 PM
See Misc in:

http://www.wholetomato.com/products/features/match.asp
feline Posted - Oct 21 2006 : 1:27:04 PM
There is no requirement that brackets should be paired up in macro's / #define lines, so VA does not attempt to highlight matching brackets on these lines. This is by design.

You can still ask VC6 to jump to a matching bracket via CTRL-]

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000