I'm coding on CLion and made this log in function. The tests are being made through the .exe because CLion's Terminal sometimes jacks up the I/O's. The problem is my .exe is not finding the files I'm specifying. It runs properly through the CLion terminal, but when shifting to the .exe it doesn't.
I've read that putting those files in the cmake-build-debug/ directory fixes the issue - and it does. Thing is, this is a group project, and by putting those files in that directory I'll constantly run into compatibility troubles when pulling from git - .cmake-build-debug would have to be pushed, thus i'd have to reload it every time. This doesn't seem very proper to me.
The other option is to put the .exe file and required .dll's in the main directory. Again, would have to update this file every single time i build the project, which also isn't a very practical solution.
So I'm asking for some help regarding what can I do to ensure my .exe searches for files in the main directory, not just on the cmake-build-debug directory. The directories are included in CMakeLists, and the .exe still doesn't find them. This is quite the issue. The project will also include some rudimental form of database, so file handling will be important. Would be nice to be able to code and build without having to manually change stuff around every single time.
Related
As stated in this post the working directory when I debug my SDL program is relative to the .vcproj instead of the .exe (which it should be IMO)
So I'm wondering if there's anyway I can change this, so when i press F5 the path will be relative to the .exe and not .vcproj?
The current (relatively easy) workaround I'm using, is simply opening up the folder and starting program from there, but I would much rather prefer simply pressing F5.
The naive answer to your question is that you can set the Working Directory option in the Debugging configuration properties to $(TargetDir). The default setting is $(ProjectDir) and by default the project directory is not where the executable file is output. However, I do not recommend you take this option, as I explain below.
You are attempting to solve this the wrong way. Your fundamental problem is that you are assuming that the working directory is the same as directory which contains the executable file. There's no reason for that to be so, and you should not rely one it. You know that the files are in the same directory as the executable and so you should look there, rather than the working directory which is only sometimes, coincidentally, the same as the executable directory.
So, instead of relying on the invoker of the process setting up the working directory to your liking, make your program independent of the working directory. You state that you wish to work with files whose location you know relative to the executable directory. So there is the answer. Construct full paths to your files, using the directory which contains the executable as the base.
If you need to find out the location of the executable, call GetModuleFileName(), and strip off the file name. What you have left is the directory which contains your executable. Combine that with the relative path of your files and your code is now independent from the working directory.
I have made a test program in Visual Studio 2013 using Direct X 11. It consists of a simple sprite which rotates slowly based on a timer implementation. The program loads and runs fine using F5 or Ctrl-F5, but when I try to open the actual created .exe (in my \Debug folder) it just shows the window then closes instantly.
Most of the answers I have read on this issue correspond to loading the .exe from inside visual studio. I have also tried Release mode but the same thing happens.
Sprite files are kept in your project folder. The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the debug folder, it is highly likely you are relying on project data files that are kept along side your source files in the project folder. When run from the Debug folder, those files are no longer visible because Debug folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I have been following some tutorials for c++ game programing. I am kind of new to c++ and I'm using Microsoft Visual C++ 2010 Express IDE. I'm working on creating a game, and when I run the program through the IDE, it shows the grass sprites as expected. But when I run the .exe file from the Release folder, it shows weird images. and when I run the .exe file from the debug folder I get a grey screen. Can anybody tell me why this is happening?
I hazard to guess that your sprite images are kept as data files in your project folder. With that I offer the following premise:
The default run-location from the Visual Studio IDE is the project folder of the project which you're executing. That is, normally it executes from the directory where your .vcproj or .vcprojx file is kept (and that is often one folder below your solution directory folder, where your .sln file is kept).
If your project runs correctly from the IDE, but fails to run directly from the release folder, it is highly likely you are relying on project data files (images in your case) that are kept along side your source files in the project folder. When run from the Release folder, those files are no longer visible because your the Release folder is your working directory; not the project folder.
There are a number of ways to solve this problem, each with its own merits. A few options are:
Post Build Step
Make a post-build step for your project that copies your data files to the $(TargetDir) location with your project. These files will then be visible in the same directory as your executable.
Benefit: Its easy.
Drawback: It will always run if you click "build solution" even if the data files are "up-to-date."
Custom Build Targets
Add your data files to the project and write a Custom Build script that performs the same copy, but also establishes an output dependency file(s).
Benefit: Almost as easy as #1, but a little more tedious.
Drawback: You may have a lot of data files and each will require its own custom build step. (Note: you can multi-select all the data files in your project, and if you're creative with the built-in macros you can have them all use the "same" build rules and commands).
Embedded Resources
Add the data files as custom resources to your executable.
Benefit: Your project no longer requires data files side-by-side with the executable since they are embedded in the resource table of your EXE module.
Drawback: Custom code is required to dynamically load the custom resources from your executable's resource table rather than off-disk. It isn't difficult at all to do, but is additional work.
There are other options as well, but I hope this gives you some ideas to start with.
I use VS2008 and try to answer your question. Right click on the project and select properties on the bottom of popup, then go to Debugging under Configuration properties. You can see command you run and arguments you pass in IDE. I guess you miss some parameters.
I created a program using C++ with netbeans on my computer. I would like the exe file to open somewhere else. It opens all fine on my computer, but i tested it on a computer in school without netbeans or cygwin. After doing research, i attempted to put a cygwin1.dll file in the same directory as my exe but that just breaks the exe even on my computer.
What is the best way to do this, from another computer? Here are some options i have so far:
1. Install cygwin.dll file on System 32
2. change variable path (Not sure what the path is, but i will find out)
Some options i want to avoid:
1. Installing netbeans or cygwin
Extra notes:
only issue i have is opening the compiled .exe file from another computer
all computers will be using windows
Links i have looked at
http://www.dll-files.com/dllindex/dll-files.shtml?cygwin1
http://pcsupport.about.com/od/findbyerrormessage/a/cygwin1-dll-not-found-missing-error.htm
Unfortunately the executable will search for cygwin.dll by name so renaming it will not work. Also, putting stuff in System32 is a bad idea mainly for security reasons (you don't want to update the school's IT department) and it's possible to mess the machine up by playing around in that folder. Changing the path is ok but, again, the permanence of the change means you should shy away from it.
If I were you, I'd create a .bat file, say myapp.bat which has the lines
set PATH=%PATH%;<location>
<myapp>
where <location> is the location of cygwin.dll and <myapp> is the full path to your executable (including the file name).
You could then double click on this batch file. The first line in this file updates the path by appending the location of the dll but only in a way pertinent to that particular session. Make sense?
I'm making changes to a form in Creator but when I build the changes are not being "refreshed".
I've gone so far as to remove every element from the form and get rid of every stylesheet but when I build the project I get the same result; as if I had never made a change at all.
What gives? Am I missing something obvious? (obvious to everyone but me.. obviously)
I guess you're using QtCreator 2.0? I found the same strange issue. You have two options:
Remove the ui_{the_name_of_design}.h from the project's build dir. Then run qmake again.
make clean or Build → Rebuild All
But the second option even doesn't help with me. By the way that's why is good to use a different build dir than that where the sources are. If some changes don't appear to be applied, just delete the content of build dir, and everything goes fine as well.
Cheers
Most likely cause if that your make procedure is not noticing the changes in the .ui file, and so it is not calling the uic tool. Try to do a make clean to see if it helps, and check your build log to see if uic is being called.
For me, the solution was to change the BuildDirectory to the same directory where the code is, instead of the **-build-desktop directory.
I stumbled upon this issue as well and one thing I noticed was that my program was still running in the background without me knowing. Ending the task through task manager fixes it and you can make changes again.
A few suggestions:
Perform a make distclean.
Use a shadow build directory. Building “inside” the source code is not advised.
Check your computer’s clock and the date and time of your files.
This thread is a little dated but since I got caught up in the same problem I thought I would share how I resolved this.
I've been incrementally building up a ui with designer under QtCreator 2.4.1/Qt 4.8.1 using a poor man's source control approach: snapshots. At one point I inadvertently created a non-shadowed build project. In a subsequent snapshot I reverted the project back to shadow build and at that point new widgets added in the ui form were no longer being recognized in the build.
Solution:
Delete stale ui_.h files from the source directory.
Delete make and ui_.h files from your shadaow build directory.
Rebuild
Latest generated ui_.h files will reappear in the shadow build directory.
No copies of ui_.h files appear in the source directory indicating that the stale files were taking precedence in the build order. Not obvious.
I have this problem and i solve it by changing the project path. I had stored the project in my flash memory when i had this problem, then i copy the project folder and it's build folder also in the Desktop and open it with QtCreator and the problem was solved.
Problem is indeed stale generated files in project source directory. This can happen both with genrated ui_*.h files, as well as with moc_*.* files. Below is not covered by existing answers, so here we go:
To remove generated files from the project source directory, without affecting Qt Creator settings or current shadow build directories, there are two principal ways, which can also be combined for extra coverage.
Go to Qt command prompt, go to project source directory and run these commands:
qmake -r
make clean
make distclean
1st one will recursively create makefiles. 2nd one will remove all files produced by building the project. 3rd one will remove the makefiles again. Then continue using shadow build from Qt Creator as before.
The problem with this is, it will leave files which are not part of the project. So if some files have been removed from project, related generated files may remain, and cause trouble if files with same name are added back. So even after this it is good idea to verify no ui_* or moc_* files remain, if you know you have removed files from project.
Use your version control software to first commit or stash/shelve all uncommitted changes, and then remove all unversioned (also otherwise ignored) files. For some version control software this may not be easy as git clean -dxf (beware, that will also lose uncommited changes and Qt Creator's custom project settings), and in that case it may be easier to just remove project source directory and get a clean checkout.
The problem with this is, if some generated files have accidentally been added to project, they will not be cleaned up with this. So it may still be a good idea to do the step 1 above too.
Above steps should be in sync so that after step 1, any files in source directory (except Qt Creators's projectname.pro.user and possible *~ backup files) should be under in version control.