My coworkers and I were just discussing an annoyance we have in Visual Studio. If you're working with a class that's inherited from another large class, like Controller, you're going to have a huge list of inherited members in intellisense. Sometimes, you only want to see your own members that you defined yourself, instead of having to find things amongst a huge list of other things.
I suppose that if you're looking for something you defined, you should know what it's called. But I know I've run into this frustration when classes get a bit more complicated. Is there a built in way to have intellisense hide the inherited things, or maybe is there a plugin somewhere that provides this? Otherwise I guess one of us has to write it.
Visual Assist X has such a feature. It allows you to push inherited members to the end of the list and more:
Access non-inherited entries quickly by having them listed first.
Scroll to see entries from base classes.
Enable this feature in the options dialog. Use in combination with
bolding of non-inherited members and shrinking for optimal efficiency.
This feature can also be enabled or disabled dynamically from the
filtering toolbar.
You may try to use this: http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx
Related
When I declare elements in the .sdef file for my scriptable application, I have the option to declare various accessors, like this:
<accessor style="id"/>
<accessor style="index"/>
However, I wonder what consequence these declarations have. So far, I could not make out any changes of behavior in my test scripts whether I add or remove accessors for index and id as long as I implement the necessary methods.
So, how do these affect anything? Are they only for documentary purposes, such as what is shown in the dictionary of the Script Editor?
Or does the scripting engine actually behave differently in certain cases depending on these declarations?
So far, I only noticed one behavior that affects them: Script Debugger appears to use them to decide how to browse values in its Explorer. But I doubt Apple added these declarations only for the purpose of this application.
AppleScript does not validate against these settings in your SDEF. However, other tools may. For instance, my Script Debugger application uses this information to control the object access options presented to the user in its Explorer viewers. Various AppleEvent bridges may also use this information to control the kinds of object access they provide to their host scripting languages. An example from the distant past was my JavaScriptOSA project which bridged AppleEvent access into JavaScript. It used the key form settings to control the keys one could use when accessing element objects.
We have a rather large solution with many projects under it. I am looking for a way to determine which dependencies are being used and which are not. We need to audit the solution and determine what is being used and what can be removed.
I have searched google and the visual studio gallery with no luck, does anyone know if a tool like this exists?
There's a couple different ways to define what "being used" means. If it's just a case of stale nuget packages that aren't referenced it's one thing, project/DLL references in individual projects that are referenced but not actually called is something else.
I can think of a couple different ways to do this. If you have Visual Studio Ultimate, you can use the "Generate Dependency Graph" under the Architecture menu to get a visualization of your various pieces, but that gets really message really fast.
Another option if you've got the cash it to buy a copy of ndepend. This thing lets you slice and dice your source code any number of ways; looking for unused dependencies is just one of the many ways you can use it to evaluate your code.
When programming a big project, you often need the same pieces of code in different pages. calling methods, returning references, ...
Now, I always need to open a page, and copy paste parts from that. but I'm getting tired of that. There should be a better way to list very often used code. I've read about snippets but they seem a lot of work. How do you manage that?
Snippets are not a lot of work if you use one of the handy snippet-easing extensions to Visual Studio. I happen to like this one http://visualstudiogallery.msdn.microsoft.com/B08B0375-139E-41D7-AF9B-FAEE50F68392 by Matt Manela. Once it's installed, you can right-click a block of code and make it into a snippet. You can also set up replacements just like when you do an if or for block with the built-in snippets.
I'm interesting with statistic and motivation of using task list in VS. Why are you use it or not? Some people i asked even want a tool, that can synchronize VS ToDo with Outlook. What do you think?
IMO you can use Todos for:
Remember that you must do something like "Todo: implement this interface"
To mark a line/block of code as instruction for another coder if your are code in a team like "Todo: you can use foo instead of bar because ..."
If you review your code you can mark any code that he can be improved like "Todo: use Linq instead of foreach"
You can replace the default tasklist-window from visual studio with plugins:
Tasklist replacement for Visual Studio
http://genne-develop.com/
I used TODO for two purposes:
To mark enhancements that can be
done at a later stage. So whenever,
there is slack time, you can pick
one of them out of your pending TODO
list.
Things that are still need to be done while I am coding - so that I can re-visit those places and fix them. This is something like bookmarks except they are visible to other folks even if I forgot to fix them.
I use TODO comment syntax - it's there in code and not in .suo file as mentioned by Benjol.
I use TODO sparingly - only when I have something that I'm not the master of (something another team-member is working on etc.). I treat it as I treat bugs - max 5 at any time.
If I need scaffolding - I create temporary classes with Fake as a prefix in the class-name.
I guess, I don't want my production code to also act as my scrum-board/task-list.
One thing to be wary of about Task Lists in VS is that they are stored in the .suo file, which (I believe) most people tend to exclude from source control.
If you use Visual Studio 2008 and have many project files within solutions how do you keep them in sync? In other words, if you change a property in one project, how do you ensure that this property is automatically changed in other projects?
Given that enough contributors are mystified about the notion of nested solutions, I'll just work from the assumption you meant "solution with multiple projects". You give them common settings by using a project property sheet. Start with View + Other Windows + Property Manager. Open one of the nodes, right-click a configuration and choose Add New. Choose a location that makes sense for the solution, the solution directory for example. Configure the settings the way you want them.
Repeat this procedure for all other projects in your solution, now using Add Existing. Every project will inherit the settings you configured in the sheet, unless it overrides them explicitly. You may have to go back to the project properties and change an override back to "inherit".
IDE support for project property sheets is a bit flaky, be sure to save them explicitly when you make a change.
I have to say, I've not heard of "nested solutions", and I'd need a pretty compelling reason to do anything of this sort. Especially considering your question really centers on "how do I maintain duplication?" since you say the solutions will share properties. It's a cardinal rule in programming "do not duplicate thyself".
You could put the required options into a compiler response file, and use the same response file in each of your .vcproj files.
See here: http://msdn.microsoft.com/en-us/library/3te4xt0y(VS.71).aspx
Basically, you create a text file like SharedOptions.rsp, and on each line of the file specify a different command-line compiler option. Like /I.\include or /DDEFINE or whatever.
Then in the c++ command-line property page of each project, you add this in the additional options box: #"SharedOptions.rsp".
Then when you edit the options in the text file, they will be picked up by all projects. It is possible that the property manager solution provided by nobugz is just a gui for this - I don't know, I am more of a command-line kinda guy.
I guess you've already done something about this in the last 2 months, but this answer is more for the googlers...
I ended up using global variables available within Visual Studio. These were variables like $ProjectName and the like. There are many available already within VS, they can be user-defined as well.