I just tested which type of code is executed by the WinForms Designer in VS 2008.
It seems that the designer is not executing the default constructor anymore.
I added a simple thing like this.Text = "foo"; nothing is changed in the designer.
Did I miss a change between VS 2005/2008? (or SP1)
tia
Did you set a breakpoint to see it skip?
If its the first form in the project, instead of starting with "Run", you can F10 (Step Over) to start at the first line of code. From there you can trace the execution.
.NET 2.0 and above use Partial Classes for windows and web forms. Is it possible that the constructor that is being hit is not default.
I placed several statements (setting the background, MessageBox.Show, File.WriteAllText,...) into the constructor including System.Diagnostics.Debugger.Break(), but nothing causes any type of response...
Not to misunderstand me, it is the behavior I'd like to have, but I know I had problems in VS 2005 regarding this issue, and I don't find any info about the fact that there is a change in the Winforms Designer.
Using the .NET reflector I don't see any additional constructors, but maybe the designer is creating one on-demand, ...
Related
When I set breakpoint in code and I want to check properties of some class in RAD Studio 2009 (Delphi project) I cannot see them in Watch List or in Local Variables list.
All I see is Pointer (Address) as TSomeClass.
Why I see this? I use also Visual Studio where it is amazing - I can see Properties and all members of some class.
I am sure the same worked in some older versions of Delphi too (There was small [+] which could be expanded to see class properties).
Is there some settings for this (I have turned off optimizations, turned on Debug...)
Maybe this is a trivial question but I am not able to continue with my project as this is really uncomfortable for me.
You are not comparing like with like. The variable in the Delphi screenshot is an interface. It has no data members, only methods. The debugger won't call methods to display tooltips, etc. since methods can have side-effects. You don't want your tooltips changing the meaning of the program.
On the other hand, your VS example is a class with data members. These are displayed in the debugger nicely in VS, and in Delphi for that matter.
I seem to be adept at making Expression Blend 4 crash at startup. The problem seems to be related to a deadlock initializing static managed and unmanaged variables as Blend first opens my solultion which has a mixture of unmanaged C++ and managed code projects. Blend crashes instantiating my ViewModel (I'm using MVVM Light in App.xaml, but I would think this isn't really relevant). This page describes in detail how to detect and correct this potential deadlock: Initialization of Mixed Assemblies
Since I'm writing code and markup in both VS2010 and Blend4 simultaneously, I sometimes accidentally create this situation, and thereafter Blend crashes when loading my solution. The Blend startup crash persists even if I correct the issue in VS2010 (VS2010 seems immune to crashing on the same solution file which brings down Blend). The Blend startup crash can happen on both x86 and x64 systems. The Blend startup crash persists even if I try to delete all output directories. The Blend startup crash persists even if I rename "C:\Users\username\AppData\Local\Microsoft\Expression\Blend".
My question is: How do I reset Blend to a state as though it has never seen this solution before?
I'm assuming this would be a valid workaround, since if I download a new, fresh copy of my source code from source control with the managed/unmanaged problem fixed, it loads in Blend4, builds, and runs just fine.
The main reason why Blend crashes is because when Intialising UI components it actually runs their constructor which can have some code for example accesses database and Blend doesn't support DB access so it might crash.
So there are two ways to find a potential problem.
Comments out all the code in the constructor of your UI ellements apart from InitializeComponent() to find out problematic code
Or
Attach Visual Studio Debugger to Blend and then rebuild the project or open XAML file which craheshes blend
To do 2nd option you would go to Debugger -> attach to process -> pick Blend from the list.
When you identify the code which crashes Expression Blend just have an if statement which will stop running the code if it's the blend who tries to execute it and if it is not just run it. So something like this:
if(DesignerProperties.IsInDesignModeProperty)
{
// This code will run when Blend renders the controls
}
else
{
// This code will run when you are running application on it's own
}
Hope this helps.
I am having a problem thats not about the code, it's about the screen in Microsoft visual studio 2008.
Actually problem is i created one utility from couple of weeks i didn't opened that utility today i opened (in Microsoft visual studio the screen appearing blank no controls are visible in that.But all the controls properties are there. I tried a lot but i didn't get solution. Last when the same thing happened i created the controls again. Now i don't want to go to create all the controls again. If any one have the solution please help me.
Before screen is like this:
Now its blank (like new page)
From your description I'm not sure if this is a application/code build issue or an IDE issue, what you could try is to reset the settings in visual studio and see if this helps.
You can do this by going to Tools -> Import/Export settings and then following the wizard to reset the settings, you may also want to perform a backup before resetting them (this is also part of the wizard) then they can be restored if this causes you further issues.
I don't have a copy of 2008 available at the moment so some menu entries may be slightly named different.
Hope this helps!
EDIT:
Now there is more information, this looks like there may be a problem with the code in the
InitializeComponent
method of the form.designer file (e.g. if you are using c# this would be something like Form1.Designer.cs and can be found by expanding the corresponding form in the solution explorer), if you remove/comment the lines that say
this.Controls.Add(this.NameOfControl)
(NameOfControl is where you would see your declared controls name)
then you get the behaviour that you are seeing, the controls do not render as they are never added to the forms controls collection but as they are declared you will still see them in the properties drop down and wont be able to add another control with the same name.
I'm working in a windows forms project using visual studio 2005 sp1, i've a lot of usercontrol that use for my user interface, yesterday i start to have problem with the designmode, when i open a usercontrol all control disappear, i check the design file and the definition of the controls is still there, when i run the app there is no problem.
I try to use this code inside the Load of every usercontrol
if (!this.DesignMode)
{
// Put some logic here
}
however, the problem persist. Today my usercontrol doesn´t display in designmode but either in runtime.
How can be posible? Any suggestion for that?
Regards,
Francisco.
I've had the same problem. Check the .Designer.cs file again and make sure the controls which disappeared are added to their parent controls. Like
this.pCheck.Controls.Add(this.pCheck_bLog_browse);
While checking the differences with previous revisions I figured out that for some reason these lines just disappeared.
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8