When running a program I need to see every time a certain button is disabled and step through the code at that point.
If I set a breakpoint with a condition
(ex: only hit when button1.enabled=false) it will only hit in that specific place.
Is it possible to set a breakpoint on the entire program so that i can see when a condition changes across many forms and locations?
You can't set one breakpoint and have it apply to every line of the file, but you can set a breakpoint on the setter of Enabled and then filter it to a specific filter condition. That would give you the desired result. (Note, you might need to turn off "Just my code", see this question for more info)
Set a breakpoint using the "New Breakpoint At Function" as described here, though in Visual Studio 2013, I seem to need to use a slightly different notation:
Then set the breakpoint to funtion:
System.Windows.Forms.Control.Enabled
in C# or for VB.NET:
System.Windows.Forms.Control.set_Enabled(bool)
(You seem to need to use the class that actually defines the property, which in case of the Button class' Enabled property, is the Control class the Button inherits from.
Ignore the warning about it not being able to find the function (it does that for properties somehow), or uncheck the Intellisense lookup.
Now look up the breakpoint in the Breakpoints list and customize the condition so it breaks on the right button
Use the Name property (or any other filter that makes the breakpoint unique) to trigger when you need it to:
When it breaks, it will break in the sources of Control (if you have Framework Source Stepping enabled), which may be confusing. Use the Stack Trace window to find the location where the method was invoked exactly.
Another way of setting the breakpoint is through the Stacktrace window. Set a breakpoint on any line that has your property of interest on it. Launch the debugger and make it break on that line, now use "Step into Specific" to step into the property that you want to break on.
Use the "Stack" window to generate the breakpoint for you:
Since in your case you're looking to break on a function from the Microsoft .NET framework, there is another way. Enabled Framework Source Stepping.
Open the Visual Studio Debugger options and enable "Framework Source Stepping" and disable "Just My Code".
Then enable the Microsoft Symbol Servers in as instructed. Now load up your application under the debugger and wait for the symbol files to be downloaded.
set a break point anywhere in your code that is somehow related to System.Windows.Forms (The constructor of your MainForm for example) and rightclick any function from the "System.Windows.Forms" assembly to load the symbols for that assembly. This will allow you to step into the "Enabled" property and set a break point there.
A full tutorial can be found here:
http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
Related
I've noticed an unexpected behavior in an object used in this really complicate framework.
What I want is that the debugger stops (like with breakpoints) every time that the object appears in an instruction, without manually add breakpoints in all the instruction where it is used/appears.
Can I do something like this in IntelliJ?
Field Breakpoint is what you are looking for.
Read breakpoint type overview to get an overview of the different breakpoint types.
Furthermore, it is possible to put a condition on a breakpoint - read configure breakpoints.
CyLog’s WildRename is a good program for performing batch-renames on files. The problem with it is that while the main window is resizable, it does not have the maximize box which makes it a little frustrating to size and use. Moreover, they have not made any updates in a long time, so the program is essentially discontinued.
I ran WildRename and used WinSpy++ to modify the style of its window to manually include the WS_MINIMIZEBOX style and bam!, it was now functioning as expected.
The question now is how to make this permanent.
My first instinct was to fire up ResHacker, but the problem is that the style that needs to be modified is that of the main window of a non-dialog application, so ResHacker has no way of doing this.
The next thing I tried was to open it in a hex-editor, to find the address(es) of the string corresponding to the titlebar. I then opened the file in W32Dasm and located the address of the code that references the address of the titlebar string. I did all this in an attempt to find the location of where the main dialog is created so that I can modify the style passed to CreateWindow(). Unfortunately, I cannot find a call to CreateWindow anywhere near the reference to the titelbar string and none of the calls to CreateWindowEx that I can find seem to be (obviously) the ones used to create the main window.
Is there an easy/automated way of modifying the style of the main window (assuming a non-dialog application)?
You could use a debugger like OllyDBG to dump the exe memory after the edit with WinSpy++, then use that exe or compare the files to see where the change is if you want to see what you've missed
There has to be a call to CreateWindow/Ex(), especially if it not a dialog from a resource. You just need to look harder. I would use IDA instead of WinDasm. It will decompile the assembly into more understandable code, and it has a built-in debugger. You can put a breakpoint on the title string and see in real-time which code actually touches it, and then follow it back to the accessing code.
I know in the older versions of Visual Studio, there was an "Add Watch" option where you can choose to stop execution when the value of the field changed. I am using VS 2010, and I can't figure out how to hit the breakpoint when the value of the field changes.
Any ideas?
Data breakpoints is what I remember, your description matches. It used a processor feature, it requires the address of the variable and the size, the processor automatically generates a trap when it detects a write to the memory address. Very nice debugging tool.
Sadly no longer available in managed code, the garbage collector messes it up because it moves objects around while compacting the heap. Which changes their address. The interface between the garbage collector and the debugger isn't strong enough to allow the debugger to track these moves while the compacting is taking place at runtime. No doubt to avoid a serious amount of overhead.
The next best thing you got is a property setter. You can set a breakpoint on it.
Right click on the breakpoint and hit Condition. You should be able to do the same from here.
In vb.net 2010 (I am using the express edition) - set a breakpoint and run up to it. Right click the variable/control name you wish to watch then select add watch from the context menu.
The watch window will appear.
You can type variable names directly in to the watch window, providing they are in scope.
You can right click on a break point and then choose Condition. In the condition box type the name of the variable and select the 'Has Changed' radio button.
I have a project in SSIS and I've added an Execute SQL Task which sends its result out to a variable. I wanted to confirm the value because I was worried that it would try to write it out as a resultset object rather than an actual integer (in this case I'm returning a COUNT).
My first thought was just to run it in debug mode and add the global variable to my Watch window. Unfortunately, when I right-click on the Watch window, the option to "Add Variable" is greyed out. What am I missing here?
I've gotten around confirming that my variable is set correctly, so I'm not interested in methods like putting a script in to do a MsgBox with the value or anything like that. For future reference I'd like to be able to watch variables in debug mode. If there are some kind of constraints on that then I'd like to know the what and why of it all if anyone knows.
The help is woefully inadequate on this one and every "tutorial" that I can find just says, "Add the variable to the Watch window and debug" as though there should never be a problem doing that.
Thanks for any insight!
I believe you can only add variables to the Watch window while the debugger is stopped on a breakpoint. If you set a breakpoint on a step, you should be able to enter variables into the Watch window when the breakpoint is hit. You can select the first empty row in the Watch window and enter the variable name (you may or may not get some Intellisense there, I can't remember how well that works.)
Drag the variable from Variables pane to Watch pane and voila!
I know this is very old and possibly talking about an older version of Visual studio and so this might not have been an option before but anyway, my way would be when at a breakpoint use the locals window to see all current variable values ( Debug >> Windows >> Locals )
Visual Studio 2013: Yes to both adding to the watch windows during debugging and dragging variables or typing them in without "user::". But before any of that would work I also needed to go to Tools > Options, then Debugging > General and had to scroll right down to the bottom of the right hand pane to be able to tick "Use Managed Compatibility Mode". Then I had to stop and restart debugging. Finally the above advice worked. Many thanks to the above and to this article: Visual Studio 2015 Debugging: Can't expand local variables?
Failed to create component 'User Control 1'. the error message follows:
'System.NullReferenceException : Object reference not set to an instance of an object.
at System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object Component, Object Value)
.............. etc..........
What should I do to fix this error?
When a User Control won't load into the Visual Studio designer here is what you need to do. These instruction are for vb.net project but c# should be similar. Also, before doing this close all open windows (or at least the source and designer files of the control you are working on.)
One last thing. The FIRST thing you should do is ensure that restarting visual studio doesn't fix the problem. If not you can try the steps that follow. These instructions assume that the errant user controls are in control library project in visual studio. If not you should be able to adjust the directions a bit to get it to work but it is much easier when the control is in its own project.
Do the following:
Make the control library your startup project.
Open the properties for the control library project and click on the debug tab.
Under Start Action click the Start external program option and browse to the Visual Studio executable.
NOTE: what this means is that when you run your solution it will fire up another instance of Visual Studio instead of actually running your solution. The First Instance of Visual Studion (INSTANCE_1) will "host" a second instance of visual studio (INSTANCE_2) when you run it.
Run your solution. INSTANCE_2 will load.
Switch back to INSTANCE_1.
In INSTANCE_1 hit CTRL-ALT-E. This will open up the exceptions dialog box. Check On the THROWN column checkbox next to Common Language Runtime Exceptions.
NOTE: This will ensure that INSTANCE_1 will BREAK at ANY runtime error even if it is hit in a try block.
Switch to INSTANCE_2. In Solution Explorer double-click to open the errant user control.
You should find that INSTANCE_1 OF Visual Studio should have stopped at the line of code that caused the designer to not load the control. Fix the code (which usually means testing for IsNot Nothing before references an object properties...but could mean other things.)
Also, sometimes I find that the control WILL load in INSTANCE_2 instead of breaking on an error in INSTANCE_1. In that case just stop debugging...close INSTANCE_2. Save/Restart INSTANCE_1 and your problem will often have gone away.
The lesson is this. User Control MUST be able to load/reference all objects and their members in order to load it into the designer. So for User Controls that will be placed onto other containers I will usually design events to notify the parent rather than trying to push objects into the child control.
Hope this helps for future reference on this old question.
Seth
Instead of the error occurring when you open up a form for editing, it sounds like this is occurring when you are already editing a form and adding new user controls. A CodeProject article that was previously mentioned shows what to do in the case of a form not loading correctly, rather than a specific user control.
Does your user control have any properties that map to custom objects (i.e. not Integer or String)? If so, the Form Designer will attempt to load your properties into the Property Editor. If showing the properties generates an error, the Form Designer will show that to you. I think this is what is happening with your user control.
If you could edit the question and add more information about the nature of the error (more of the error text), it would assist others in helping you better. Alternatively, see if you can find the property that might be causing the error (e.g. whether any property relies on a non-null value being set). You can also take a look at this MSDN article for tips on how to limit the control for just run-time.
Thanks, Seth, for this post! Your solution helped me nail down the error. The only thing I would add to this is that when "INSTANCE_2" loads, you may need to actually load the project file in INSTANCE_2. I needed to because I wasn't dealing with a control library, but instead had custom User Controls defined in the same project that the forms were located in. Once I loaded the project in INSTANCE_2, I opened the erring form and that caused INSTANCE_1 to pop up to the line of offending code in the User Control.
I have found that this error often occurs when control dlls are not building properly. 95% of the time this is remedied by simply restarting Visual Studio.