As a newbie, I need to uninstall cmder (the command line emulator). I have searched extensively to find a way to do so, to no avail. Some allude to the fact that one should simply delete all files, but if this is the correct approach, how can one be sure that all files have been deleted completely?
For example, I tried this earlier and was left with several mysterious files on my system that couldn't be deleted.
Any help with this is much appreciated. In particular, how has anybody else gone about uninstalling cmder?
Thanks in advance!
According to the instructions here, you need to do the following
Open cmder and run the following command cmder.exe /UNREGISTER ALL.
Run Regedit.
Go to HKEY_CLASSES_ROOT\Directory\Background\shell, delete cmder folder.
Go to HKEY_CLASSES_ROOT\Directory\shell, delete cmder folder.
Done!
Related
I have recently started using r markdown and I am having issues with installing pandoc-crossref in window.
I have tried approaching friends on getting the set-up but to no avail. I have tried searching on the web but couldn't find anything useful. I tried following the directions here text to no avail. I will be grateful if anyone knows where i can get the set up and how to go about installing it.
You don't give any information about what errors you receive, so it is hard to provide useful help. This being said...
Trying to guess what your problem is. It is likely that you are getting the error could not find executable pandoc-crossref when trying to compile. Assuming that that is the case, your problem might be the following. Notice that pandoc-crossref.exe is not an installer, but an executable, so double clicking on it in an attempt to install it will do nothing except bring up a terminal for an instant. Is that what you have done? Where did you place it?
Leaving pandoc-crossref.exe e.g. in your downloads folder or on your Desktop would give the could not find executable pandoc-crossref error when trying to compile, because the executable needs to be in your $PATH, or pandoc will not be able to find it and run it.
A possible solution. If my guesses above are correct, you might be able to solve your problem by placing pandoc-crossref.exe inside your pandoc program folder, where your pandoc.exe file is, which is by default in:
C:\Program Files\Pandoc\
So try to place pandoc-crossref.exe in that folder and see if it works.
If this does not help. Say exactly what it is that you tried to do, what errors you encountered, and maybe include a screenshot.
What am I doing wrong?
1. I write some code in Qt Creator, it works.
2. I save all, copy the folder with all the files in it to another location for safekeeping.
3. Then I write more code. This additional code doesn't work and I've gone too far to undo it.
4. So I close Qt, delete that folder, move the earlier one back to where it was originally, and load the older version.
But Qt still gives me the same errors that the newer code gave me, and won't run. It seems to remember this newer (bad) code even though it no longer appears anywhere in Qt - and the problem persists over computer reboot. I feel I'm missing something very obvious, but Mr Google can't help at all.
Try Build->Rebuild all. Your IDE is probably caching some of the previous results for performance reasons. I had the problem once using Qt Creator, and it solved it for me.
Delete the build folder. All that the build system knows about is the built files being newer than your now even older sources*. So a build won't succeed since plenty of intermediate files are wrong.
By the way, you really should be using version control, not moving folder around. I suggest git via smartgit, but that's just my personal preference. It's effortless.
* A build system could remember the absolute timestamps of the source used in the build and rebuild if they change, not only if the sources are newer than the results.
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.
I've been following the Code Blocks installation tutorial for SFML: http://sfml-dev.org/tutorials/1.6/start-cb.php
I did everything in the tutorial, but when I compile, I get the error saying:
"The program can't start because sfml-system.dll is missing from your computer. Try reinstalling the program to fix this problem.
I've been scouring Google for solutions, but nothing has worked so far. Stuff I've tried:
-Moving the sfml-system.dll into the same directory as my .exe
-Changing the "debug" linker options to static and dynamic.
Any help on this issue will be greatly appreciated, thanks!
Carpetfizz
First, your link is for 1.6. The most recent version is 2, which might be better. (in terms of organization/ability etc - more time of improvements added to it in theory).
In the download of SFML I have had, the DLL's are in the SFML/bin folder, or something similar. When I have gotten this error before, it was when I was trying to link dynamically to them and the DLL was not, as you said, in the directory.
Ah. Assuming the directory is not the problem (you could try to put it right next to it just to be sure), looking at the tuturial in question says that you need to also define SFML_DYNAMIC. For some reason I feel like it said if you use gcc this did not make a difference, but that was probably the 2 tuturial (which might have different listed version of gcc), so I would try that. (near the bottom of the page).
This popup comes up as soon as the app is started:
The program can't start because MSVCP90.dll is missing from your computer.
Before anyone says "install the VC++ runtimes", wait! If I rename the folder containing my .EXE then the app runs. If I rename it back, it breaks. The app has been running for weeks without any changes to my system/VS installation (2008 SP1), we suddenly spotted this error a few days ago.
Lost as to why the name of the dir is causing issues... again this has not changed in months and all our resource paths are relative anyway, e.g "../someOtherDir/...."
It doesn't just do this on my PC, we have the /bin dir (the one containing EXE) in SVN and suddenly everyone started seeing the same issue, even though the binaries themselves seem just fine. Is it possible some additional data got put into SVN and that's the cause? Since it's not just one PC, there must be something either in SVN or the EXE itself...
Note this popup comes before our code even gets to run.
It seems that there is a .exe.manifest file lying around, specifying some other version of MSVCP90.dll. Removing this file should do the trick (In theory the manifest is the solution against dll hell, but in reality it is just a new PITA).
Try rolling back to some earlier SVN revisions and see if you can identify a change which made it stop working. A binary search will be most efficient for this. PATH settings might also be an issue?