How can I check if a directory is currently being used in Qt? By "being used", I mean that a file in this folder is open (a .exe for example, as I am working on Windows).
I tried with QFileInfo::IsWritable() but it doesn't seem to work on directory, plus it's only to know if you can rename the file apparently (I tried this on my .exe and the result was true, even if my .exe was being... executed).
Any idea?
Related
Atom seems to assume that certain folders are non-project-source folders and thus should not be included in search results and fuzzy finder (cmd+t). I've noticed the following folders are treated this way and the text for these folders are also displayed darker in the file tree:
node_modules
lib
log
That's all fine and dandy, except that I have a lib folder that is in fact important project source code that I would like to access via fuzzy finder. Is there a way to instruct atom to include the lib folder in fuzzy finder results?
The Fuzzy Finder ignores files that are ignored by your VCS (Git in your case?) by default.
You can change that behavior by removing the check on the "Exclude VCS Ignored Paths" checkbox in the general settings:
In your case, is the lib folder part of your .gitignore file? If it is, then Atom wouldn't include it in its search results.
I have tons of files in my home directory (~), and each time I open Brackets, it tries to load and index all the files there. Eventually, after freezing for a minute, it throws the error:
Error Indexing Files: The maximum number of files have been indexed.
I can of course switch directories after this freeze, but how do I set the default directory for Brackets to be another directory (not the home directory), thus avoiding this freeze each time Brackets is initiated?
Brackets should be remembering whichever project you had open last. Your state settings file may be corrupt. Try these steps:
Quit Brackets
Navigate to the following folder:
Mac: ~/Library/Application Support/Brackets
Linux: ~/.config/brackets
Find the state.json file and change the projectPath parameter to a new default path
If state.json cannot be found, make sure this folder has write permissions for your user account
If the above did not work, try opening the state.json to see if it's corrupted (possibly by a buggy extension). If all fails delete the file altogether and restart.
If I have multiple binaries whose sources are scattered in various subfolders of an overlaying folder, would windbg have access to them if only the topmost folder was included in Source Path? As opposed to having to reference each project folder of each relevant binary separately.
Assuming, of course, that the sources are unique in the mentioned folder structure, i.e. there are no multiple versions of one and the same project, source, etc.
If you specify the parent folder for the source files in source path then it should traverse through the subdirectories to find the source files.
Note that it will perform a signature match against your source files, in the same way that Visual studio will complain that the source files are different to the loaded dlls.
The relative locations of the source files must match the original locations so if your source files are located in a different structure then you will need to do a manual load/browse to specify the location of the source files.
Can’t answer exactly, but I often have 3 top (parent) directories, and each have approximately 4-5 levels of sub directories. No problems. However nothing beats using a source server
Short answer: NO.
From windbg's help:
For each directory in the symbol path, the debugger looks in three
directories. For example, if the symbol path includes the c:\MyDir
directory, and the debugger is looking for symbol information for a
DLL, the debugger first looks in c:\MyDir\symbols\dll, then in
c:\MyDir\dll, and finally in c:\MyDir. The debugger then repeats this
process for each directory in the symbol path. Finally, the debugger
looks in the current directory and then in the current directory with
\dll appended to it. (The debugger appends dll, exe, or sys, depending
on which binaries it is debugging.)
You can move all projects' .pdb files to one folder or change projects properties and setup the linker to create the .pdb file in a specific folder so you have to reference only one.
I've been doing a bit of debugging on this myself. From what I can tell, the relative path of the file found from the SourcePath needs to match part of the end path of the path embedded in the PDB. For example:
I have a file on disk at:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\thread_local_key.rs
The path of the file embedded in the PDB is:
/rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs
✔ This SourcePath, and any below it, correctly finds the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust
❌ This SourcePath, and any above it, does not find the file:
C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src
Notice how with the failure case, the relative path to the file would begin with library\. The library path component is the first part of the path that is not found in the embedded path. I assume it does a path check for every relative address, recursively:
thread_local_key.rs
windows\thread_local_key.rs
sys\windows\thread_local_key.rs
src\sys\windows\thread_local_key.rs
std\src\sys\windows\thread_local_key.rs
library\std\src\sys\windows\thread_local_key.rs
etc.
Here's the deal, I've compiled a few classes into a jar file with a manifest pointing to the main-class. It works just fine on my computer.
I transferred the jar file onto another computer which I'm supposed to give a demonstration tomorrow on and well, here's where things went downhill.
Winrar was not installed, so I installed it in order to extract the folder I had my jar file in. I unknowingly associated winrar with jars which I fixed by changing the default open program with jre7/bin/java.exe. However, the jar file does not self-execute as it did previously. I'm thinking something's up with the registry.
Stackoverflow, what do you think?
I guess a simple solution would be reinstalling the JRE.
You need to reset file association for ".jar" files, jar files are not executed by "jre7/bin/java.exe". so what you should have done before choosing default program to "jre7/bin/java.exe" was to simply uninstall WinRAR or remove its association from the WinRAR settings. So now, open start menu, search and open regedit.exe goto HKEY_CLASSES_ROOT/.jar and delete every value excluding "(Default)" who's value data should be "jarfile". the reinstall jre and reboot pc . THAT'S YOUR SOLUTION.
I have created an application that compiles and runs like a charm on OS-X. I would now like to start getting it to work on Windows. To start, I copied the project to a windows machine and just tried to compile, but got this error:
:: warning: Qmake does not support build directories below the source directory.
Any ideas?
Set the shadow build directory to some folder on the same level of your project directory:
folder/
project/
project-shadow-build-release/
project-shadow-build-debug/
You can do this in the "Projects" view, via the toolbar on the left. To me, this warning was just an annoyance, a project never failed to build because of it.
Don't copy your project.pro.user file when you are copying a project from one machine to another, or from one directory to another. When you open the project, Qt Creator will offer to create a new build directory in the proper place.
Andref gave the correct answer to resolve this warning, but you may want to understand why this requirement exists.
In fact, the build directory must be at the same folder level as the project (i.e. it can't be above or below). The reason why is that the linker is called from the build directory. Hence, any relative paths to library files will be different than what you entered in your project file.
It kinda sucks. I like to put all intermediate files in their own folder. But you simply can't with qmake.
.pro.user are generated files by Qt Creator. They are unrelated to qmake and should not be touched (and not put into a VCS for that matter)
Just remove the files with the pro.user extension , worked for me
I also got this, trying to compile a project created on linux.
Another way to solve it is to change the paths in the .pro.user file (in the directory of your project)
Right Click on a project: Set As Active Project
Click on the Projects button (The one with the spanner image)
Edit build configuration : Debug / Profile / Release / and change the default directories, OR just uncheck the Shadow build check box.
The Build directory path should now change to black, from red