I'm a beginner in C++ and I started an Udemy course. In that course they recommend using CodeLite as IDE, so I decided to give it a try. In the course, they write a basic program that displays "Hello world!" to show how the IDE works. They compile then execute it, and a terminal window opens with the "Hello world!" message like normal.
In my case, after following the setup process step by step and using the exact same code as them, when I compile and execute the code, my terminal flashes for a split second and then disappears. In their video the terminal remains open but I thought that since they have an older version of CodeLite maybe in the newer one that I have, the terminal is supposed to close by default.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause"); on Windows, but in my case the terminal keeps behaving the same, and CodeLite doesn't report any problems. I've also tried cin.get(); with no success.
Any idea what could be causing this problem?
I had the same problem and I did these steps to solve the problem:
Uninstalled CodeLite.
Installed MinGW correctly.
Then reinstalled CodeLite.
Then did tutorial steps: Click Scan then select MinGW.
After I did these steps, it worked normally.
I had the same problem running Codelite on OpenSuse Leap 15.1. I eventually found a very simple answer. Go to the Settings menu, select Preferences and then Terminal, on the left towards the bottom. Change it to konsole to use the standard terminal, rather than the codelite-terminal.
I know this is an old question, but did not see the answer that worked for me. Debugging (F5) will close the terminal after completion.
However, running/executing (CTRL+F5) will not. Leaves terminal open. At least this is the case for me, and hopefully this helps someone out.
I know this is an old question, but CodeLite has a Project-level setting for "pause when execution ends" which will pause the program before the terminal closes so that you can see outputs and the like.
To turn on just right click on your project, go to settings, and it should be in the center of the general tab.
I went online and found people saying that a way of keeping the terminal open is by adding #include and system("pause");
And this is the wrong way to do it - the desire to leave the window open/closed is not meant to be controlled by your program; but the thing calling it. For example, you break the ability to run it as part of a headless script.
Much better would be to run it in debug and put a break point at the return of main, or to find the configuration option in your IDE that stops it closing the window.
I am not aware why CodeLite would behave like that. If you really added some pause or blocking call and it still closes, it looks like it is not really running the program (e.g. something breaks before that or something is misconfigured).
First, try to open a terminal yourself (e.g. cmd or PowerShell on Windows), and execute your compiled program there -- that way, the terminal will remain open. If that works, then compilation went fine, but something is wrong with CodeLite's configuration, most likely.
Otherwise, as a last resort, since using CodeLite is not strictly required, simply switch to another IDE/toolchain, e.g. Visual Studio (on Windows).
For some reason, after closing and reopening CodeLite, it now works, the terminal remains open when I run it from the IDE. I don't know what solved the problem since I've closed and reopened CodeLite at least 5 times before this without anything happening. Thanks for the help though.
I had the same issue. What I found wrong was that the compiler that I installed was 32bit and I was using the 64bit CodeLite version . Try Installing the 32bit CodeLite version and it should work fine.
It worked for me.
I had this problem also, I tried uninstalling and reinstalling code lite but the problem still occurred.
I went back and checked the Environment Variables in control panel and I had placed the systems variables in "Path" to the incorrect Bin directory.
I corrected the entry, uninstalled and reinstalled code lite again and the problem was resolved.
Hey I also had the same problem, doing the same course! What I did was to relocate my mingw-w64 folder, deleted the earlier path from environment variables and added the new path. I uninstalled CodeLite; not saving the user information. I actually downloaded the 14.0.0(64-bit) instead of the newer version 14.0.1(64 bit) . Then I did the steps that Frank tells you and it worked out for me.
I am completing the same Udemy course and encountered a similar problem of the console closing immediately. I encountered the problem for a workspace with 1.) a long name and 2.) ending with an underscore "_". I reduced the size of the folder name which also involved deleting the trailing underscore. This appears to have solved the problem. I encountered this problem with one of Frank's provided workspaces so I knew it was not a compiler issue.
I had an issue with section 20 of my Udemy course because it had parenthesis in the workspace folder name. "(STL)" at the end. Once I got rid of the special characters, it worked fine.
If pause("system"); or cin or restarting Program and whole PC solutions are not working, then make sure to:
Copy your code.
Create new Project and past your code there.
Make sure the new project is selected before trying to double-click it.
Notes:
You can now delete the old not working project and rename your new project.
I don't know what's the reason of the problem, but I did that and it worked for me.
You need to make sure if it is 64bits CodeLite then you have installed 64bits MinGW. Through the IDE itself, you can re-run the setup wizard
Restarting Codelite worked for me ...
I have searched and found no answer to this
I have a weird problem when running executables through developer studio (2008): a basic 'hello world' exe works OK when created through the usual dev studio project creation mechanism, but when trying to run a library based program the software crashes with STATUS_BAD_NETWORK_PATH. The program uses Qt and zlib behind the scenes and is written in C++, but (as far as I'm aware) is not dependent on any particular network locations on initialisation; we do have Sophos installed on the PC too.
The weird thing is that one cant even step into the main: the program fails well before this with the error. If we plug the network in, it starts up just fine ... The odd thing is this only occurs on a specific 64 bit Windows 7 machine.
Does anyone have any tips as to how to trace where the issue is? We've tried tracking using procmon but it is not very revealing; no obvious failures up to the point where the program crashes.
We have now figured out the answer. It transpired that there were 2 issues:
Firstly a wrapper .bat script that was launching developer studio was setting the PATH environment variable: a location in this path was being specified using a UNX style path (e.g. \\a\location\somewhere) rather than a mapped drive. The executables were not actually using this location but when the network was unplugged this it seems that this was disrupting things from dev studio
This, in tandem with a network configuration error on the PC, meant that deep down in the runes, something was failing.
So - advice if you see such an error
Check your PATH and make sure it is sensible
Look in your PC's configuration logs, and see if you can see any networking issues
...
I have wrote a program which tries to write a file in C:\windows\ directory. I have tested the program in several PCs with winXP, win7 (64 & 32 bit).But when i install it in my client's PC it crashed with the message : TODO ( file description ) has stopped working
Please if anybudy knows any solution then reply me.
The solution is not to write to the C:\Windows folder. You're not working for the Microsoft Windows team.
It is quite awesome that you gave your client a "TODO:..." product? Please edit the version info to reflect your product name~
As for crash scenario:
Check if your application really needs Admin rights, if yes, start with "run as admin" and see it it solves the problem.
View the problem details in either "Stopped working dialog box", or in Windows event viewer. In both, you can see the exception code (like 0xC0000005) and the DLL name. For this you should enable PDB file generation by enabling /DEBUG flag in linker setting (this is not same as _DEBUG macro in compiler settings!).
Put some file-logging or message-boxing (temporary) and see till where program goes properly. Yes, you need to make few changes, build and give again to your client (and please no "TODO" as product name - be professional!).
There are a few possible causes, among them no write access(perhaps the user running the program does not have write access to C:\Windows folder. Try to manually create a file in that location.) or faulty programming.
In any case, you have a few things to try to figure out the problem. If debug is impossible you should put the sensible parts of the code in try catch blocks (for example the part where you write the file). And if error is caught you can output a message about the part where the error is. You should also include a logging solution and add logs in various places of the code. After you install the updated application, when you get an error, look up in the log file to see where the code stopped.
Is it possible you have UAC turned off, but your client doesn't? Or, would the client's user not have administrative rights? A user process would not be allowed to write to the c:\Windows folder. If that's the case, trying to create a file would throw an exception.
The proper place to create a data file would be:
Application Data under the user's folder, if the file is per user.
ProgramData (Win7) or Application Data under All Users (XP), if the file is per application (log or so).
Apart from the issue of permissions the first thing that will cause your application to crash like that is the runtimes not being installed on your client's PC. Does your install package install the MSVC runtimes? If not, have you installed the MSVC redistributable runtimes on that PC?
"I have wrote a program which tries to write a file in C:\windows\ directory. "
That's your problem right there. Don't do that.
Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.
I'm using WMI's CreateProcess() to run an installation bootstrapper process (setup.exe) on a remote machine. The setup.exe is happily able to run .msi packages but for some reason it is not able to run the vcredist.exe packages that are used to redistribute the MS VS 2008 SP1 C++ Runtimes.
What I'm seeing is that the redist package is able to extract itself into a temp folder in the root of the C:\ drive, e.g. C:\a26f91763649ecad76a09d or some such, but after that the process hangs around.
I don't know what to do to debug further - I suspect that there is a modal dialog in the hidden windows station awaiting dismissal, but I can't see what the text is. Process Explorer isn't yielding much either.
Anyone got any suggestion? The problem applies equally in Windows 2000 as in Windows 2008. We used to use a DCOM-based method to launch setup.exe remotely and this did not exhibit the problem.
Can anyone shed any light on what might be going on, or how to diagnose further.
Many thanks,
Stephen
User error! My suspicion about the modal dialog was correct. It seems that invoking the setup.exe files with a relative path somehow caused the command line arguments to get stripped when passed to the nested exe, so they ran in full UI mode! Invoking with a fully-qualified path resolved the problem.