| T O P I C R E V I E W |
| coderanger |
Posted - Sep 21 2007 : 3:23:04 PM
It would be great if any blocks of code are #ifdef'ed out by a define not defined, then the entire block is coloured grey. It would make it a lot easier to see code that doesnt apply with the current configuration. |
| 10 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Sep 25 2007 : 11:37:41 AM
coderanger are you after well defined, statically defined blocks of code being coloured? e.g. "_DEBUG" code, and things like that? Or are you after VA working out what is supposed to be inactive on the fly?
We are considering a feature to colour specified blocks in a different colour, which might help you if you want specifically defined blocks coloured:
case=8914
However it would be no use for colouring blocks based on your current compiler settings.
sl@sh I do like your final solution, but I am also concerned about the run time effect. Background highlighting works for find references, but it is not completely robust, it is possible to upset it if you try hard.
Building on the "highlight current line" approach might help here, but that would currently exclude VC6, which is not ideal. |
| sl@sh |
Posted - Sep 25 2007 : 10:19:02 AM
The problem is twofold:
1. Even with all the neccessary information it isn't always possible to decide whether or not a block is active - as a matter of fact it can be both active and inactive, as feline pointed out.
2. Should VA aid it's users by disabling one of it's more useful features for parts of the code it 'considers' unimportant? Or should it offer full support (including syntax coloring) even for parts of the code that doesn't seem to be active. There are good reasons for both behaviours - and to be honest, I wouldn't favor the former over the latter.
Suggestion:
Instead of greying out inactive(?) conditional blocks of code, how about just doing some minor formatting to all conditional code, e. g. set the background color to some user-defined color? The default color could be set to white, just like normal code. If a user wants to distinguish conditional code blocks from other code he might set it to e. g. light grey. Apart from that, syntax coloring should remain as normal.
I'm saying 'conditional blocks of code' without qualifying 'active' or 'inactive blocks. The reason I'm doing this is that normally all conditional blocks of code should be both active and inactive under certain conditions - else the condition wouldn't make sense! So I don't request VA to decide on whether or not a code is active currently - just have it mark the block as 'potentially active/inactive'.
This suggestion avoids problems 1 and 2 above, and in addition to that users get the default behaviour by doing nothing at all (i. e. by not defining a distinct background color for conditional code).
It still serves the original purpose of visibly marking potentially inactive blocks of code, although the user will still have to decide on whether or not it is active under the current conditions. This might be considered a drawback by some, but personally I'd consider it a good thing: conditional blocks of code should prompt the coders to some thinking!  |
| coderanger |
Posted - Sep 24 2007 : 2:37:46 PM
Its not for me to suggest how it would be done tecnically, its just for me to suggest that it would be nice if it were done. It would make editing code much easier and more applicable, which surely is VAs "raison d'+?tre".
However, if it 'cant' be done then fair enough; its a shame but I understand. |
| feline |
Posted - Sep 24 2007 : 1:20:03 PM
As this FAQ entry explains:
http://docs.wholetomato.com?W321
VA is designed to help you with active and inactive code. In part the question hinges on why the code is inactive. If it is debug / release specific code then this is probably code you are going to be frequently editing, and want VA's help to edit.
If, as in the FAQ example, it is OS specific then you probably still want help editing it.
At the practical level sometimes it is very hard to work out if code is active or inactive without actually compiling it. Plus what happens when the code in a header file is active in "foo.cpp" and inactive in "bar.cpp" in the same project? All you need is to add the right #define statements to the top of the cpp files, and this happens. |
| coderanger |
Posted - Sep 24 2007 : 04:59:14 AM
Sure, but I still want it and think its a valuable addition. |
| sl@sh |
Posted - Sep 24 2007 : 04:24:01 AM
If you mean build-dependent #ifdef blocks that rely on symbols #defined within the project file, not in the code, then this might prove difficult. I remember feline saying as much in another thread concerning these symbols. VA currently does not interpret project files, only source code.
Moreover there is the question as to what the purpose of VA is: as I understand it, it is meant to provide help on any parts of the code that might be used eventually. So if there is code that is not meant to be used at all, delete it. If it is meant to be used within another context, then it makes sense to let VA provide you with it's abilities to better edit it!
There's also the added problem of automatically adapting the coloring whenever the project files are subject to change.
I do see the merit of this request, but I also see the difficulties... |
| coderanger |
Posted - Sep 23 2007 : 03:17:26 AM
Yes, I dont use VS2005 (yuk, toooo sloooooowwwwww and annoying), we use just VS6 at work currently. |
| hotzenplotz |
Posted - Sep 22 2007 : 6:42:23 PM
I don't really get it - VS2005 already does that (although it doesn't work perfect - e.g. eclipse does a far better job).
Do you mean VAX should do it for 2003 and 6.0?
|
| coderanger |
Posted - Sep 22 2007 : 3:30:57 PM
Yeah, I have been wanting this for years and thought, hey why dont i just post it and see if someone else thinks its a good idea. |
| znakeeye |
Posted - Sep 22 2007 : 05:34:50 AM
Yeah, I really like this :) |
|
|
