I have an application that connects to an API. The API needs a logout function to be called when work is finished so that its system works properly. I have a function that connects to this API, does some work, and then logs out and it works correctly. The problem is when the program crashes, or I need to close it during work.
I have added a call to the logout function in the FormClosing event in my MDI parent form. Will this work for all cases of closing the program?
To be more specific - I know, that clicking on the red X button will trigger this event. But will closing the program from the Windows' Task Manager also trigger it? And will stopping the program from Visual Studio (during development, when it was also run from Visual Studio) also trigger it?
It is triggered when the user closes the program.
It is triggered when task manager closes the program, but only some fragment of the code in FormClosing will execute, rest will be also killed
It is not triggered when Visual Studio stops the program.
It is not triggered when the power to a computer is cut off.
I have a pretty simple wpf application. Works great on my machine. But when I install it on another machine, the browser's loadCompleted event does not fire. Based on other similar questions & answers, I have tried:
- use navigated event instead of loadCompleted - does not fire either
- use windows form browser instead of wpf browser - does not fire
- ensure app is fully loaded before navigating: tried putting the navigate call in the window's Loaded event, even threw in a 5 second sleep for good luck - does not fire
Like I said, works like a charm on my machine, both from within Visual Studio and when I execute it from the command line.
So I'm thinking it's something about the other machine. Any ideas what environmental factors would prevent the loadComplete/Navigated events from firing?
Thanks!
[edited: just tried it on another co-worker's machine, and the loadCOmpleted event does not fire there either. So it seems to just fire the event on my machine/the machine it is built on. Not sure if that gives anyone a clue to this frustrating little mystery...)
OK, well this is mildly embarrassing. The events were indeed firing, but my messagebox messages were not showing up. Before it could get to that step, the app encountered a fatal error. There were two problems that worked together to cause me days of untold angst:
1) I had deployed the debug version of my app to the two remote machines. Neither of those machines were developer machines, and they did not have the debug version of the redistributable Visual Studio gunk. So it was failing trying to load one of my dlls, because of the dependency on the debug libraries.
2) Poor error handling failed to catch this error, so it just looked like the event was not firing.
Lesson learned: make sure you have proper try/catches !!
From this post I got this:
For debugging a button click without setting breakpoints:
Start the app with the debugger.
Get to the state immediately before the intended click.
Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
Go to the app and press the button -- the debugger should take over and drop you into the event handler.
This is Not Working for me however it was working for me Before. Dont know why its very awesome but not working now. Anyone?
Please reset your VS settings, and then debug it again.
I just use a simple Winform app in my side:
https://onedrive.live.com/embed?cid=55E83A59BF9AE3EB&resid=55E83A59BF9AE3EB%21893&authkey=AEmhE8zHWfnS4gE
It works well using the following steps:
(1)Debug the app(F5).
(2)Click "Ctrl+Alt+Break", I will get the result like the following screen shot.
(3)Click F11(Step Into).
(4)Click the button1, it will hit a breakpoint in the button1 click event, and then using F11 step into. The same steps as the button2 event.
I just use the default VS settings with the latest VS2015 Enterprise version 14.0.25431.01 update 3. So you could test it using the above simple sample, it still has this issue in your side, maybe we could think about the VS settings and the VS setup.
I've been debugging a WPF application bequeathed to me by a gentleman who is fond of making interesting architectural decisions. As a result, I'm having trouble locating the code that runs when a user clicks an on-screen menu item. Following the binding from the view to the viewmodel got me to some collection of "control functions" that's initialized at startup (apparently, all manner of different controls with varying functions had to go into a single collection). I've managed to find some code that's triggered by the click, but it's too deep, too far removed from the click event to be of any use to me.
This got me thinking...
In Visual Studio, (I'm using VS2015) when the application isn't running, if you select Debug -> Step into, debug is triggered, and then the debugger breaks on the very first line of the code (in my case the constructor call of the class that inherits from System.Windows.Application)
Isn't there a way to do this while the application is already running? Let's say I've started a WPF (or WinForms) application, a window has been displayed, the UI thread is running and awaiting user input. The user clicks on a button, and some code is executed. But unless there's a breakpoint in the code, the debugger doesn't do anything about it. As I've explained, this can be a problem if I don't know which code is actually run. Is there a way to tell Visual Studio, "listen, if the user clicks on something, break on the first line of (user) code triggered by this action." Is that possible?
I am trying to debug a windows form application which has a large number of events: button presses, timers, etc..
Is there a way to catch every line of code being executed by the application without setting a break point?
edit:
The program was not written by me, so I am unfamiliar with the code. I wish to step through the entire program, catching every line of code being executed. Setting break points in every event is impractical as various controls are created dynamically.
For debugging a button click without setting breakpoints:
Start the app with the debugger.
Get to the state immediately before the intended click.
Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
Go to the app and press the button -- the debugger should take over and drop you into the event handler.
Note: This will not work if Paint, any Mouse event, or probably some other events are handled. The debugger will drop you into those handlers any time you attempt the steps above.
If you're using the Ultimate edition of your Visual Studio 2010 you can use its new feature called IntelliTrace (previously Historical Debugger). This will allow you to do exactly what you want - be able to see all method calls and events that happened during execution of your program, and you'll be able to jump back to the event which you need.
To enable IntelliTrace, go to Tools → Options → IntelliTrace, and check the "Enable IntelliTrace" checkbox, and select one of two modes: "events only" or "events and call information", then run your application with a debugger (F5).
The difference between the two modes is that the latter uses the profiler to collect all runtime information, so you get a complete call stack, however you won't be able to use edit-and-continue features of the debugger.
You can find more in this series of articles, and of course, on MSDN.
You could also try a code coverage tool.
For example, if you have Resharper and dotCover, you can run your application (via the dotCover->Cover Application... menu item) and when the application finishes, dotCover will show you which lines of code were run in the VS IDE by highlighting them in green. Lines of code which where not run are coloured in red.
I don't know if there are other tools which do this, but it's an option.
I developed the Runtime Flow tool to solve exactly this problem - to understand a large unfamiliar .NET codebase via realtime function calls monitoring. It's similar to IntelliTrace, but places more emphasis on control flow than on debugging.
Why would you want to break on every line? This would be very onerous and time consuming. If you want to see the activity of your program as it executes, use a logging mechanism or Debug.Writeline to output information to the Immediate window.
You cannot trace lines of code, but you can use Trace.TraceInformation calls where you want to have an idea of what's executed. There's also Debug.Write. Both output will write in the output window of Visual Studio.
Another solution would be to add logging to your application, for example with log4net, but that may be overkill for your needs.
This isn't exactly what you're asking for, but in case you didn't know you can toggle an existing breakpoint on or off. In your case, you could add break points at key places throughout your code and just disable them when you don't want to debug them. That way, you'll be able to re-enable them later when you want to use them again.
Enabling/disabling is available through the Breakpoints window found under the Debug > Windows > Breakpoints menu (CTRL+D, B). You can also include "Function" and "File" columns in the window, which might help you identify which breakpoints are in the event handlers that you care about
Not really, but you can set one breakpoint and single-step (F10/F11) through the rest of the code.
Nope 'fraid not - you need to set each breakpoint yourself.
If it helps F9 is the shortcut key for assigning a breakpoint - just set a breakpoint on the start of each method and use step through (F10) / step into (F11) from there.