When I use ReSharper to add a using directive (using Alt+Enter) it removes "unnecessary" parts of the namespace. I prefer using the full namespace which is also the behavior of Visual Studio.
Example:
namespace MyCompany.MyTool.Data
{
// This is what ReSharper gives me:
using Core;
// This is what I want:
using MyCompany.MyTool.Core;
// ...
}
Which setting do I have to change in ReSharper 4.5 so it uses the full namespace?
I don't have ReSharper 4.5 installed at the moment, but in 5.0 there's an option at the Namespace Imports pane called Prefer fully qualified using name at nested scope. It might be the one you're looking for.
Related
I read the article about AndroidX Refactoring Support at https://android-developers.googleblog.com/2018/09/android-studio-32.html.
To my understanding AndroidX will work instead of android.support.v4 and android.support.v7, right?
So in my new project, I don't need to import android.support.v4 and android.support.v7 again, right?
If you go to android.com's page Migrating to AndroidX, it has a list of which AndroidX package replaces each legacy package. It also has a list of which namespace a particular class has been moved to. To convert to using the AndroidX version, you have to replace the appropriate 'artifact' in your gradle dependencies, and you have to change your import statement to whatever namespace the class is in now.
For example, android.support.v4.app.FragmentManager is now called androidx.fragment.app.FragmentManager. So you'll need to change your import statement, and you'll need to add the relevant AndroidX library to dependencies in your build.gradle file:
implementation 'androidx.legacy:legacy-support-v4:1.0.0'
So yes, you don't have to reference android.support.v4, you have to reference the appropriate new library.
I have 2 LESS files. Globals.less and Site.less. Globals.less contains all of my global (go figure) variables and an import to a CSS reset definition. Site.less contains the styles in use.
Globals.less:
//Imports
#import "CSSReset.less";
//Colors
#color-background: rgb(0, 0 , 0);
Site.less:
#import "Globals.less";
body {
background: #color-background url('/Images/BackgroundTextureBody.png');
}
The problem is this: In Visual Studio #color-background in Site.less is underlined and the error is "Undeclared variable", but the LESS compiles to CSS just fine and the background color is properly set to #000. It is more of an annoyance than anything, but I lose Intellisense and I get warnings in my error list. I would like the editor to act as expected and be able to "see" my declarations in Globals.less when I am editing Site.less. Am I doing something wrong, is this a bug, or is my environment not setup correctly?
To get intellisense for a particular less file you can add a reference path in the same way you would to get intellisense in a js file.
Example
/// <reference path="Globals.less" />
#import "Globals.less";
body {
background: #color-background url('/Images/BackgroundTextureBody.png');
}
It appears that Visual Studio (or it's LESS interpreter) does not understand the scope of the variable within the imported Globals.less
Importing variables is a normal and common thing to do so I'd suggest that it's a bug or missing feature in your Visual Studio setup.
It turns out that I was using an older version of Web Essentials 2012. The first thing I should have checked and failed to do was to ensure that my environment was up to date. Updating Web Essentials to the latest version corrected the issue.
I know that since Groovy 2.0 there are annotations for static compilation.
However it's ease to omit such annotation by accident and still run into troubles.
Is there any way to achieve the opposite compiler behaviour, like compile static all project files by default and compile dynamic only files chosen by purpose with some kind #CompileDynamic annotation for example?
I have found some (I believe recently introduced) feature which allows doing so with Gradle.
In build.gradle file for the project containing groovy sources we need to add following lines:
compileGroovy {
configure(groovyOptions) {
configurationScript = file("$rootDir/config/groovy/compiler-config.groovy")
}
}
or compileTestGroovy { ... for applying the same to test sources. Keep in mind that neither static compilation nor type checking works well with Spock Framework though. Spock by its nature utilizes dynamic 'groovyness' a lot.
Then on a root of the project create folder config/groovy/ and a file named compiler-config.groovy within. The content of the file is as follows:
import groovy.transform.CompileStatic
withConfig(configuration) {
ast(CompileStatic)
}
Obviously path and name of the configurationScript may vary and it's up to you. It shouldn't rather go to the same src/main/groovy though as it would be mixing totally separate concerns.
The same may be done with groovy.transform.TypeChecked or any other annotation, of course.
To reverse applied behaviour on certain classes or methods then #CompileDynamic annotation or #TypeChecked(TypeCheckingMode.SKIP) respectively may be used.
I'm not sure how to achieve the same when no Gradle is in use as build tool. I may update this answer in the future with such info though.
Not at this time, but there is an open Jira issue here you can follow to watch progress for this feature
There was also a discussion about methods for doing this on the Groovy developers list
I'm trying to compile a VC++ project I've inherited that uses MSXML2. This is an ATL .EXE project. A header file includes the following:
#include "msxml2.h"
using namespace MSXML2;
Preprocessor definitions include __USE_MSXML2_NAMESPACE__, which I added to the project because without it the MSXML2 namespace was undefined. Attempting to build this project I receive many errors of the form:
error C2039: 'IXMLDOMNode' : is not a member of 'MSXML2'
These errors are produced by declarations like the following
CComPtr<MSXML2::IXMLDOMNode> pNode;
Other members are not found, including IXMLDOMDocument and IXMLDOMNode.
You can fix this
Include msxml2.h header.
Remove USE_MSXML2_NAMESPACE and using namespace MSXML2 code.
Use CComPtr<IXMLDOMNode> pNode; without namespace.
I've seen many projects using import keyword to ask Visual C++ to generate the header file from TBL using MSXML2 namespace. However, using header and linking to lib is my favorite way to avoid using import keyword as it is not c++ standard. The bottom line is to avoid mixing the two approaches when refreshing old projects, which will lead to problems like this.
I'm working on a cross platform project that uses STL. The other compiler includes STL support by default, but in VS2005 I need to add the following before the class definitions that use STL items:
#include <cstdlib>
using namespace std;
Is there a VS2005 option that would set this automatically? It's just a bit tedious to work around. I'm just trying to avoid lots of #ifdefs in the source -
EDIT: The other compiler is the IAR workbench for the ARM 926x family. Perhaps I should get them to explicitly do the includes?
Also - is "std::map<>" preferred over "using namespace std; map<>" ?
All compilers should require you to include those lines. If they don't, then they're just encouraging you to write non-portable code because you're relying on certain headers to be included automatically and you're relying on certain names to be in scope implicitly.
I don't mean to say that those two lines should always be required, though. I only mean that if the rest of your code is written to use things declared in the cstdlib header and in the std namespace, then those two lines need to appear first, and the compiler shouldn't act as though they are there when they really aren't.
Check whether your other compiler has some settings to disable this implicit code. If it doesn't, then it's probably a very, very old compiler, and you should consider not using it and not supporting it anymore.
Try refering to STL components by their namespace-qualified name (i.e. std::vector).
Doing a global 'using namespace std' is usually a bad idea.
Or maybe I'm not understanding the question.
The IAR compiler does not support the std namespace (I'm not sure why, because it does support namespaces in general if I remember right).
If you look in the runtime headers for IAR you'll see that they do some macro gymnastics to work around that (the runtime is licensed from Dinkumware, who provide runtimes for quite a few compilers).
You may need to do something similar if you want your stuff to work in multiple environments. A possible cleaner alternative is to just include the "using namespace std;" directive. I might be wrong, but I think the IAR compiler essentially ignored it (it didn't mind that you were using a namespace it didn't know about). A lot of people will think that's ugly, but sometimes you gotta do what the compiler you have wants you to do.
In general you should avoid "using namespace X", especially in header files (because everyone who includes your header gets that namespace too whether they want it or not), and especially for namespace std (because it's so big and the potential for name collisions is big).
Instead, in header files refer to names by their fully qualified form, e.g.:
// for plain functions
void foo(std::map<int> intMap);
// for classes
class person {
std::string name_;
public:
person(std::string name);
// ...
};
Then, in code files, you can do "using", but prefer using specific items in the namespace rather than pulling in the entire namespace. e.g.:
using std::map;
using std::string;
void foo(map<int> intMap) { ... };
person::person(string name) : name_(name) { ... };
etc. This way you avoid impacting others including your headers, and you avoid pulling in potentially zillions of names that might cause a collision with other stuff.