| T O P I C R E V I E W |
| wlater |
Posted - Feb 09 2009 : 8:09:30 PM
This idea may be pushing the borders of what VA is intended to do and to be fair, it really should be Microsoft implementing this enhancement. But I figure I have a better chance of getting results asking Whole Tomato Software... 
Visual Studio supports highlighting User Keywords via the UserType.dat file. However, there is only one User Keywords coloring allowed mapped to a single UserType.dat file. What I would like as a minimum is to be able to switch to another UserType.dat file while within Visual Studio to color a new set of User Keywords. This would take some reparsing time of course but is much better than exiting VS, renaming a different .dat file to UserType.dat and then restarting VS. This approach probably would require Microsoft to modify VS. So not likely to happen.
That's where you come in. It would be great if VA added the capability *in addition* to what's already in VS. And do it better than MS of course.  I would envision multiple User Keywords options listed under the VS Fonts and Colors list. Could be as simple as:
VA User Keywords #1
VA User Keywords #2
VA User Keywords #3
Each being able to be set to individual colors. Then elsewhere in VA would be an options window with the mapping of these to UserType.dat-like files and probably an Active/Inactive option for each (would likely have many fixed mappings but would not always want all of them active). Or maybe all of the aspects in a single options window rather than split between two. Exactly how and where the options are set is not critical. What's most important is the ability to have multiple User Keyword groups set to various different colors.
[Edit: Changed User.dat to the correct UserType.dat filename] |
| 8 L A T E S T R E P L I E S (Newest First) |
| spectecjr |
Posted - Mar 07 2009 : 4:51:10 PM
quote:
Originally posted by feline
I have done quite a bit of cross platform development, Windows and Unix, and I never heard anyone worrying about using the inbuilt types. I can see a concern if you are moving between 32bit and 64bit systems, but if this is really important you want the compiler to catch it, and complain.
Actually, it does matter in game development; you ideally want to force people to use sized-types instead of the defaults, and to avoid system types (like BOOL). |
| feline |
Posted - Feb 19 2009 : 5:20:13 PM
We may add support for changing the background colour as well as the foreground colour over time. We are making some changes to colouring in the next build, but it is not going this far.
One thought on depreciated functions, if you already have a list of these you could try adding:
#define depreciatedFuncOne
#define depreciatedFuncTwo
etc, lines to VA's StdAfx.h file. This should cause them to show up as italic macro's, which if you realise they are functions, not macro's, is a clue.
What you are doing here is interesting, but I am not sure how many of our users would actually use this, or benefit from it. We have to be careful where we spend limited resources.
Edit VA's "StdAfx.h" file as explained in this FAQ entry:
http://docs.wholetomato.com?W302
After modifying this file you need to rebuild the VA symbol database for the changes to take effect:
VA Options -> Performance -> General -> Rebuild symbol databases |
| wlater |
Posted - Feb 18 2009 : 11:45:24 AM
Well if it's a maintenance nightmare, it'll be my maintenance nightmare.
As to built-in types, the most common example I've seen is math intensive stuff (think flight controls and the like) typedef'ing a REAL type and switching back 'n' forth between float and double. Mostly in cases where you're checking calculation accuracy on a desktop machine (and so double) and then running on an underpowered embedded system (and so using float). Not super common, but it does happen.
True about the deprecated functions, but then again, it's a matter of catching it as early as possible. Using that same argument, I could argue that the coloring of types is unnecessary because if I get the type name wrong, the compiler will catch it and complain. The idea is to catch it while I'm right there working with the specific piece of code. This holds for many of VA's features and is one of the best aspects of VA in my opinion.
Being able to change to different sets of stable include directories sounds like a good idea and would accomplish part of what I have in mind. I'll look forward to trying it out. Might you consider allowing the user full control over the visible aspects for stable directory symbols (i.e. foreground and background color, bold, italic, underline)? I realize there's an issue with multiple attribute application (e.g. method coloring AND stable directory), but with a user warning and a stated visible attribute application order, it could be useful. But I'll take italic only over nothing.
In the meantime, I'll try to think up some other uses for my enhancement request and continue to lobby. Not too much though, I promise.
|
| feline |
Posted - Feb 17 2009 : 10:37:18 AM
This just sounds like a maintenance nightmare to be honest, maintaining all of these reference files, and keeping them up to date.
I have done quite a bit of cross platform development, Windows and Unix, and I never heard anyone worrying about using the inbuilt types. I can see a concern if you are moving between 32bit and 64bit systems, but if this is really important you want the compiler to catch it, and complain.
The same with the depreciated functions, since this is much more reliable than just colouring the screen.
Stable directories and italic symbols, we are considering a change to how this works, to make it easier to change between different sets of stable include directories:
case=21844
which might help you to set up different groups of stable directories. This will only make things italic, but it could help. |
| wlater |
Posted - Feb 12 2009 : 12:41:27 PM
Yes, I use the Stable symbols in Italic VA option and find it to be useful in a similar, but not exactly the same, way as UserType.dat. And to be completely honest, I was using UserType.dat before I began using VA and have not fully adjusted my use to take into account things that VA now does for me. IG??m getting closer though.
The update with the IDE open is just a nicety. It's helpful when updating the UserType.dat file. It's true that you don't often need to update it, but when you do it's a pain to keep exiting and restarting which is common during update to make sure you get the new items listed correctly. It would be nice to have as a feature, but not crucial.
As to complete, yeah it *was* pretty complete until MS just did a major MFC update in the 2008 SP1 feature pack. There's a whole bunch of new stuff now! IG??m not complaining though, some of the new MFC stuff is nice.
I can understand your concern with N settings. Even a fixed N=1 would be a major improvement though if VA implemented the ability to change what file to use as UserType.dat. Although with N=1, this would probably require the ability to reparse the new file with the IDE open. A fixed N of 2, 3 or 4 would probably do the trick nicely without the need to re-parse with the IDE open. I agree that people might start wanting this to be solution specific (it would be handy), but even non-solution specific is better than not at all.
Oh, I did think of a couple of more uses if I had more than one UserType.dat file in play. I could use one for deprecated MFC, ATL, and CRT functions. This would be very easy to put together because I could cut and past right from VS Help. Would probably higlight them in Red. Another possible use would be for code that needs to run both in Windows (or Unix) as well as an embedded environment. In such a case, itG??s common to never use the standard C++ types directly and always go through typedefs depending on the platform compiling to. However, thereG??s no way to enforce this and so direct use of C++ types can sneak into the code over time. I could use a very simple UserType.dat file to highlight (probably also in Red) any standard C++ type. So the file would be quite short and have entries like:
char
int
float
double
unsigned
I appreciate you even thinking about considering the enhancement. It's not really a great match to the types of things VA currently does and Microsoft really should have done this (multiple files) years ago since they have had the UserType.dat feature implemented since VC6 at least, possibly earlier. I'll fully understand if the perceived benefit doesn't justify the effort on your end. It's simply something I've wanted for a long time now. |
| feline |
Posted - Feb 12 2009 : 10:58:06 AM
An initial answer is that VA's setting:
VA Options -> Advanced -> Fonts and Colors -> Stable symbols in Italic
is supposed to help achieve something similar.
Why do you need to update the files while the IDE is open? It sounds like your current file is already very complete.
One reason I am concerned here is that you have N files, so N settings. I am wary of anything that sounds to open ended, you could end up adding a lot of settings. Especially if people start wanting these files to be solution specific rather than global. |
| wlater |
Posted - Feb 11 2009 : 8:41:47 PM
Fair enough. I think itG??s a lot simpler than it sounds. Let me try to explain it better by describing how I currently use UserType.dat and then expand from there.
UserType.dat is just a text file with one text string per line. Here are a few sample lines from mine:
_AFX_NO_OCX_SUPPORT
_AFX_NO_OLE_SUPPORT
_AFX_NO_OLEDB_SUPPORT
_AFX_NO_RICHEDIT_SUPPORT
What I have in my UserType.dat file is a rather long list of Windows/MFC/ATL etc. related text strings. Macro names, class names, global function names, etc. ItG??s over 50,000 lines long now. I use this in Visual Studio to highlight all these names with a pale blue background like below:
This has a number of advantages. 1st, at a glance I can see how much the code depends on outside Windows/MFC/ATL etc. library items. This is important to me because I also write code for other platforms including embedded processors. Code with lots of light blue highlighted items isnG??t going to port easily. Also, it gives me a heads-up if I use a name for my own code that is already used in the Windows/MFC/ATL libraries. Depending on the name, I might want to change it if it shows up light blue so that it does not get confused with the Windows/MFC/ATL name. Also, if I know I want a library item, it better show up light blue or else I have the wrong name. These are all minor advantages I admit, but they are handy.
Note that the MicrosoftG??s coloring of UserType.dat items is a simple text match, no syntax interpretations, and appears to be very fast. It does not appear to slow down noticeably, even with my 50,000+ line file. VS loads the UserType.dat file every time VS is run and does whatever parsing is needed while loading. Any changes made to UserType.dat will not take effect until after VS exits and then is started again. And there is ONLY one UserType.dat file allowed. It must be named that, be kept in the correct directory, and will be loaded when VS starts.
Now what I would really like to do is have the equivalent of multiple UserType.dat files. Then I could do even more useful things. 1st, I could split up my 50,000+ line file into a better breakdown: Win32 in one file, MFC in another, ATL in another, maybe even CRuntime library in one and/or the STL in another. Probably create one for Boost as well and also for internal libraries. Again, these would be simple text files and would be simple text matching (no syntax knowledge). There would need to be a configuration window where the user would map the files to coloring name. For instance:
User Type #1 mapped to MFCTypes.dat set to pale blue background
User Type #2 mapped to BoostTypes.dat set to pale green background
User Type #3 mapped to InteralLibOne.dat set to bold text on pale yellow
On startup, each of the files would be read, sorted and kept in RAM (I assume that would be needed for quick-lookup) and then any text that matched items in any of the files would be colored accordingly by VA. Also have a check box by each to be able to turn each User Type # coloring on/off would be useful so the mappings could be kept while turning off a particular User Type coloring. Finally, a button to re-read the files, sort the data, and update the coloring while staying in VS would also be very handy.
|
| feline |
Posted - Feb 11 2009 : 12:35:19 PM
What specifically are you trying to achieve here? This sounds like it could turn into quite a lot of work, but I am not clear how or why this helps. |
|
|
