I've installed both FreePascal compiler and OmniPascal extension for VisualStudio code, but code completion doesn't work. In the manual you are saying that I need to write the path to Delphi compiler int the user settings, but nothing is said about FPC.
Set the omnipascal.freePascalSourcePath setting to the folder that contains the FreePascal sources
Set the omnipascal.defaultDevelopmentEnvironment setting to FreePascal
Restart Visual Studio Code.
Example:
"omnipascal.freePascalSourcePath": "C:\\lazarus\\fpc"
"omnipascal.defaultDevelopmentEnvironment": "FreePascal"
This will instruct the OmniPascal language server to lookup Pascal units (.pas and .pp files) in that directory and all its subtrees recursively.
Related
I have in the project a cpp file that is outside the dir tree. Resharper c++ doesn't enable inspection, such as go to definition.
Resharper version 2022.1.2
Visual studio 2019 and 2022
It didn't help enabling
options> code editing> c++> inspection> enable on external modules
Also, it's not an external file, it's a cpp that is part of the project.
There's also this
https://www.jetbrains.com/help/resharper/Reference__Options__Tools__External_Sources.html
but the option doesn't appear under tools.
The problem is with resharper; VS inspection (go to definition) works fine.
I found the problem, and it's weird. Say I want to add to the project the file:
c:\prj\confstruct\src\debug\mpir.cpp
which is outside the project directory.
If in cmake I use the abs path (given as a parameter to add_executable):
/prj/confstruct/src/debug/mpir.cpp
then resharper ignores the file.
If I add the drive letter:
c:/prj/confstruct/src/debug/mpir.cpp
Then resharper works fine.
Make sure that the file is used somewhere in your project, i.e. is included into one of your .cpp files. Turn on the "Enable inspections, quick fixes and context actions in files external to the solution" option in ReSharper settings:
I install my development tools from zipped distributions and by setting paths by self so I can easily continue using after system fails/reinstallations as well as copying into other PCs I have.
I am trying to use Android Studio on a path portable as possible, and it is mostly going well. I extracted android studio under t:\Tools\Android\android-studio\ and use following command in CMD console to start it.
set ANDROID_SDK_ROOT=t:\Tools\Android\sdk\
set ANDROID_HOME=t:\Tools\Android\sdk\
set ANDROID_SDK_HOME=t:\Tools\Android\.android
set ANDROID_PREFS_ROOT=t:\Tools\Android\.android
t:\Tools\Android\android-studio\bin\studio64.exe
Today I found out this is not enough for my purposes after a plugin fails to load because of incompatibility, that the path to "Android Studio system files" is still set to
%USER%\AppData\Local\Google\AndroidStudio4.1
I couldn't find a proper answer on how to set this path under t:\Tools\Android\ through an environment variable. answers I could find are just mentioning this path but does not tell about changing it. (or just missed in like millions of topics containing same search terms)
Can you please show a way, if there is any, to change this folder path?
This does not seems to be done by simple environment variables.
However, it seems a bit of manual work makes it possible.
editing editing these lines in t:\Tools\Android\android-studio\bin\idea.properties file
idea.config.path=${idea.home.path}/.AndroidStudio/config
idea.system.path=${idea.home.path}/.AndroidStudio/system
idea.plugins.path=${idea.config.path}/plugins
idea.log.path=${idea.system.path}/log
and then using this environment variable
set STUDIO_PROPERTIES=t:\Tools\Android\android-studio\bin\idea.properties
Visit Making Android Studio Portable (2017+ versions) for more info for portability
I am trying to follow this guide
to configure VC++ for WxWidgets. I got stuck here.
So for Core wxWidgets libraries to include, I did include wxmsw31u[d]_core.lib and wxbase31u[d].lib under Linker>>Input>>Additional Depenedencies. That is all to it right?
As for Linking with correct runtime library, can someone tell me how that is done? I manage to get here but don't know how to set the indicated settings.
Please help. I really appreciate it.
When you want to debug your app the debugger must know where in the compiled code is each function used. In jargon, the "debugging symbols". Windows puts these symbols in the compiled executable, while Linux uses another, .devfile.
When you compile code (your app or wxWidgets library) you must tell the compiler whether you want a "Debug" version or a "Release" one.
If you want the debugger to be able to step into wxWidgets code, then you must compile wxWidgets in "debug" mode, which will add the character d to the library files built. So, you must add, for example, wxmsw31ud_core.lib to your app dependencies. Notice the d between u and _. Use the file explorer to see all files generated by wxWidgets compilation process.
Perhaps you don't want all this wxWidgets "debug". Then use another wxWidgets compilation route and add wxmsw31u_core.lib instead of the d'd version. Still you can compile your own app in debug mode, but not being able to step through wxWidgets internals.
Now for your app, a) do you want a single executable file also containing wxWidgets code? or b) let your app in a .exe file which uses as needed external .dll files?
a) is called "static linkage" while b) is called "dynamic linkage"
As you can see, there are four combinations of debug/release & static/dynamic. You must choose one "runtime library" to link to your app.
The table in the wiki shows the switch and MSVC lib (select the desired combination in the 'properties' page) to use in your app; and macro definition required to build wxWidgets if you use nmake instead of the already provided configurations in VS.
Take a look at docs\msw\install.txt for more info.
The best advice I give is that you look into "minimal" sample project. Load it into VS and read every option. You can even make a copy, change some file names and use it for your own app.
I recommend using the official instructions instead of the wiki, they're simpler and, if you look at the last paragraph, you can see that you don't even have to link the libraries manually with MSVC.
You also don't need to do anything special to link with the correct version of the CRT, the defaults are just fine.
I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.
I found a great C++/ODBC example here...
The project I downloaded builds great and everything works. However, when I copy the .cpp and .h files into another project, I seem to have a linking problem.
The SQLConnect function in sql.h is the one I want. When I right-click this function in the easyodbc.h file in the project I downloaded, it jumps to the declaration in sql.h. Life is good.
However, in the project I created, when I do this it jumps to a UNICODE definition in sqlucode.h. This seems to be causing problems and my test project crashes.
I don't have an #include for sqlucdode.h anywhere in my project, yet it still resolves the declaration to the one in sqlucode.h. How can I prevent this? Thanks.
Seems like you have a preprocessor problem rather than a linking problem.
You probably have a preprocessor definition for UNICODE (or _UNICODE) in your project file. In Visual C++ 2005 and 2008 you can fix this by going to your project properties and changing Character Set from Use Unicode Character Set to Use Multi-Byte Character Set. When you apply this setting, Visual Studio fixes up the right preprocessor and linker settings for you.
If you have an earlier version of Visual Studio you can still fix it by changing the preprocessor definitions for UNICODE and _UNICODE to _MBCS - it's just you'll have to find them yourself.
EDIT: I just downloaded that example code and tried it - good news, it's exactly as I guessed, change to a multibyte character set and you'll be fine.