It's not about code, though. But my console applications written in VS will exit as soon as the application finish its job (no matter debugging or directly opening by double clicking *.exe). How can I prevent this cause I need to see the output.
Actually it is about code. In your console application you have the main() function and because this is C++ it will end with a return 0; statement (or similar). To make your app pause when it has finished all you need to do is alter that last line to something like return fgetc(stdin); and it will now wait until you press the enter key.
But to expand on what BeyelerStudios said you might want to go a bit further than that and make it a bit smarter. So:
#ifdef DEBUG
_tprintf(L"Press the Enter key to exit\n");
return fgetc(stdin);
#else
return 0;
#endif
The Visual Studio Output window will display any string passed to the function OutputDebugString in DEBUG configuration. So if you just want a string you can look at, you can use that.
Passing arguments into you function is probably the best solution, you could still pause in release builds, but it is going to require the most work.
There is one final method. Rather than hit F5 open a command prompt (WindowsKey+R and type CMD), cd to the write directory and run you exe from there, all output will remain in the window after the program exists. But this won't help if you need the debugger.
Hope that helps.
Related
I am trying to run an AHK script to open/show/minimize teams depending on the state of the app. I currently have the same functionality work for the windows calculator, but when I copy/paste the same solution, AHK fails to run teams. Currently, this is what I am working with
F11::
If WinExist("Teams ahk_class ApplicationFrameWindow")
{
IfWinActive
WinMinimize
Else
{
WinGet, winState, MinMax
If (winState = -1)
{
WinRestore
WinActivate
}
}
}
Else
{
run ahk_exe Teams.exe
WinWait, Teams
WinActivate
}
return
however, it seems line 24 (run ahk_exe Teams.exe) is causing the issue. When I run windowSpy, I get the following:
When I replace ahk_exe Teams.exe with ahk_pid 6440 I get the same issues. Has anyone else had this issue and found a way around it?
I feel like some of these terms need to be cleared up a bit:
ahk_exe is the name of the executable file (i.e. .exe) that the process is associated with. Normally, just using the run command generically with the name of this file would do nothing, as AHK has no idea which folder this .exe is in. This just happened to work with the Windows Calculator app [calc.exe], since that was a program that Windows allows you to run anywhere you want. The solution is to tell ahk which folder the .exe is in so that it can run it.
If you want to test whether or not a specific program parameter for the run command will work properly, you can open up a command prompt window and try the command, replacing AHK's run with the Commandline's start [ex: run calc.exe becomes start calc.exe].
Additionally, ahk_pid is not a constant number that persistently associates with a program. In fact, every time you run a program, even if it is the same exact program, Windows will assign a new PID to it every time. Futhermore, because a new one is assigned after the program is launched, we cannot use it to initially launch a program.
Important!: This code immediately below is unsafe and can corrupt your installation of Teams. Please see Update 1 for more info and a better alternative.
Here is a solution that launches the Teams app (Teams.exe) from the default installation location in C:\Users\[YOUR USER NAME HERE]\appdata\local\Microsoft\Teams\current\Teams.exe
run "%LOCALAPPDATA%\Microsoft\Teams\current\Teams.exe"
Hope this was helpful. If you have any additional questions, please lmk
Update 1:
While looking back at my original solution, I found out that directly running the Teams.exe file was not a good solution, as it has the potential to corrupt the installation of Microsoft Teams (which happened to me). As such, in order to run Teams the way the developers intended it to, I am opting to run the Program's shortcut file (i.e. the "Microsoft Teams.lnk" file in the %AppData%\Microsoft\Windows\Start Menu\Programs\ folder). Upon inspecting this .lnk file, I found that it contained additional logic and calls to MS Teams' Update.exe file that help prevent these issues from occurring. So, the new Run code to start MS Teams would be
run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
With that out of the way, we can now integrate this new run command back into OP's program. From what I could understand of the original code, these were the objectives OP was trying to code (if any of these are incorrect, please lmk and I can update):
If Teams is running and the currently active window, minimize it.
If Teams is running, but not the active window, make it the active window
If Teams is not running, run it and make the active window once it opens.
So, we can effectively boil down the logic to be something like this (in pseudocode):
If Teams is running
If Teams is the Active Window
Minimize Teams
Else (i.e. Teams is NOT the Active Window)
Make Teams the Active Window
Else (i.e. Teams is NOT running)
Run Teams
Wait until Teams is done opening
Make Teams the Active Window
Let's start with the code to detect if Teams is running. Currently, the source code uses this to try to detect is Teams is active: If WinExist("Teams ahk_class ApplicationFrameWindow"). Ignoring whether or not this syntax is correct (I've never seen both a WinTitle and ahk_class parameter used in the same "" block for WinExist), using the ahk_class, at least in this case, might not be the best option available. In the the Windows Spy screenshot that OP kindly provided, we can see the ahk_exe of Teams.exe would be much more specific than the ahk_class of Chrome_WidgetWin_1. As such, can use If WinExist("ahk_exe Teams.exe") instead for this program to detect if MS Teams is already running.
The next thing I want to touch on is that when Teams is "closed" i.e. by clicking the X button in the upper right corner of the screen or even when closed using the WinClose command, it's default behaviour actually minimizes it to the tray, from where the WinActivate command can be used maximize it, similar to how it would be if it was instead minimized to the taskbar by clicking the - button instead. As such, depending on personal preference, you can have Teams either minimize to the taskbar or minimize to the tray and still work the same functionally with the rest of the program. Although this was not a requested or mentioned feature by OP, I feel like this is still a useful behaviour to mention/ include in this response.
Next, the original code that the original script was using to Activate a non-active but still running MS Teams was as follows:
Else
{
WinGet, winState, MinMax
If (winState = -1)
{
WinRestore
WinActivate
}
}
While the additional checks and logic that OP implemented could be useful in some scenarios, I feel like it could effectively be shortened and replaced with just a simple
Else
WinActivate
The last change I made that deviated from the original script was just the bit that ran Teams if it was not already open. I feel like I've already discussed the changes enough above, but in summary: run ahk_exe Teams.exe was replaced with run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
Final Code:
F11::
If WinExist("ahk_exe Teams.exe")
{
IfWinActive
WinMinimize ;Use this if you want to minimize Teams to the Taskbar
;WinClose ;Use this if you want to minimize Teams to the Tray
Else
WinActivate
}
Else
{
run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
WinWait, Teams
WinActivate
}
return
This was a bit longer than usual, but I hope this was helpful. Once again, if you have any Questions/ Comments/ Concerns, or just want more clarification, feel free to ask.
I start off the program with debugging with a successful build. Then it loads up a screen that says enter a character. I enter a letter. As soon as I press enter the program crashes. Why is this happening? I am running Visual Studio 2015 edition.
When you run a program in visual studio (with debugging), the program will execute and the console will automatically kill itself after it's done. The reason it doesn't immediately kill execution is because it is waiting for your input. It is hard to be certain without seeing your code itself, but you are likely not waiting on user input after that initial input. Instead, your program probably just prints something to the console with some intermediary calculations and/or format adjustments. You should add breakpoints if you want to run with debugging, but otherwise I would suggest that you run without debugging if you want to manually close the console.
I am new to the debugger. When I step over a line of code, I was wondering how to step back. Now I'm realizing that the code can't be executed backwards? Do I have to restart the activity in debug if I want to step back to old lines?
Also, if you don't mind, what is the force-step-into command?
Don't think that is possible. Android works like all other debuggers, which are more or less waterfalls over the code. You can't really step backwards, but thats where breakpoints come in. Place a break point before the line you wanted to step backward on and rerun your app, it'll keep going until it hits that line.
To explain Force-Step-Into I'm going to explain Step-Into/Over first. Step-Over sees the line you want, and steps over it, stopping at the line in the same file after the function call was made. Step Into on the other hand steps into the function call and stops on the first line of that function call, could be in a new file or a new location. In Android, there are a lot of functions that are considered "Black Boxes" where you don't really care what they do since they most probably don't affect the code (Like the Log.d function). Force Step Into allows you to step into those if you'd want to.
Source: https://www.quora.com/How-would-you-explain-in-one-line-about-Step-over-Step-into-Force-Step-into-and-Step-out-of-Android-studio
Notice that you can set conditional breakpoint, i.e. breakpoint will stop execution only if x == 57 (so you don't have to skip manually all 56 breaks). Very useful. Just set breakpoint, click with right button on it and set your condition.
May be Frames can help to check method() calling stack in debugger window
YES, you can!
According to the Android Dev Summit in 2019, now you can step back while debugging with Android Studio!
Check out the live demonstration.
All you need to do is to press the Drop Frame button in your debug view, and then Resume Program. Then you will automatically get back to the last break-point.
Note: the device should run at least Android 10.
I don't think that is possible, like #OmegaNalphA mention, but you can have a look on the stack trace and see the order your code is executed.
StackTraceElement trace = new Exception().getStackTrace();
Log.d("myapp", trace.toString());
Here is a small program to reproduce the behavior using Cygwin 2.5.2, under Windows 7.
#include <windows.h>
#include <process.h>
int main(void)
{
const char * const argv[] = {
"c:/Windows/System32/notepad.exe",
0
};
Sleep(5000);
return spawnvp(_P_WAIT, argv[0], argv);
}
This is built as follows:
$ gcc -mwindows spawn.c -o spawn
The good: Correctly, this program does not start with a console window. We can navigate to its directory with Windows Explorer and launch it. Nothing appears on the screen as the program begins executing and reaches the Sleep(5000) statement.
The bad: After five seconds pass, the spawnvp call is executed, and the program gets a console window! Notepad launches and its window shows over top of this console window.
Can someone explain why, and how to make this go away? Only Notepad should show, not any spurious console window.
Of course, if we spawn a console program, that program should get its own console window. That's not the issue here; the parent is getting the unwanted window (and the child isn't a console program at all).
Update: I'm now rebuilding Cygwin, hoping to be able to add some debug print statements into the complicated guts underlying the spawn* functions, to see at which point the window appears.
I tracked this down. All Cygwin spawn* and exec* calls go through spawne which relies on child_info_spawn::worker class member function, implemented in winsup/cygwin/spawn.cc.
This function contains the following:
if (mode == _P_DETACH)
c_flags |= DETACHED_PROCESS;
else
fhandler_console::need_invisible ();
The culprit is the call to this fhandler_console::need_invisible which allocates a console. For some reason Cygwin thinks that an invisible console window needs to be created if the calling application doesn't already have one. Unfortunately, the plans to create this invisible window don't pan out as planned; we get a visible window.
If I comment out this call to need_invisible and rebuild the Cygwin DLL, the problem goes away.
Visual C++ 2005 Professional
Debug/Win32
Windows 7 Enterprise 64-bit
I set a breakpoint at my program's entrypoint. My program crashes before reaching that breakpoint. When the unhandled exception occurs (Access violation reading location 0x00000000.), I click on Break, and set a breakpoint where the current instruction pointer is located. Restart the debugging session and the program stops on the new breakpoint. I scroll up to the top of the current function, __tmainCRTStartup(), and set a breakpoint at the opening brace for the function.
I stop/restart the debugger again, this time stopping at __tmainCRTStartup(). By this time, all of the DLL's have been loaded, and if they needed to, run their load functions. Press [F5] to run to the original breakpoint. The Next Statement pointer is pointing at a call to WinMain(...).
Stepping over this statement causes the unhandled exception. Stepping into the statement takes me to this statement: "return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);". Stepping into once again takes me to the Disassembly window, where I see the next statement to run: "jmp AfxWinMain (563AFAh)".
I can step through the assembly code, but I cannot make out what it is trying to do before it tries to dereference a pointer in one of the registers, which holds a value of zero (0).
I read another post about a C program crashing before reaching main(). Even though tagged with "C", many responders mentioned constructors of a static instance of a class being a possible culprit. Others mentioned DLL's loading and running their own startup code that might crash the program, but the DLL's all seem to load and I have evidence of at least one DLL running its startup code, before the program gets to __tmainCRTSetup() .
Can anyone help me understand this? Knowing why it's doing this should help me understand how to fix it.
Thank you!