I have a function that causes an exception in the designer. Can I avoid the call of the function if the designer loads it. Is there an attribute or something that is better than try catch?
Some more details:
I mean the visual studio designer for win forms. My form is using a signleton wich calls LoadProject() on initialize. Now I want to avoid that the designer calls the LoadProject() function.
Assuming this is WinForms - You can check if you are currently in DesignMode and just have your function return immediately.
There are some complexities that are fully explained in this article including a solution.
There are a few ways of detecting whether or not you are in design mode:
Check the value of the DesignMode property of the control. This does not work in a constructor of a control though, as it only returns true if the control has been sited, which does not happen until after the control has been created. It also has a bug whereby a custom control inside a custom control will always return false
Check whether the current application's path contains devenv.exe using Application.ExecutablePath.ToLower().IndexOf("devenv.exe"). If is does, the control is being instantiated by Visual Studio. A bit horrible, but it works.
Check LicenseManager.UsageMode for the value LicenseUsageMode.Designtime (have a look at my answer to Detecting design mode from a Control’s constructor for more details). Note that this does work in the constructor.
Wrapping the call to your function in any of these checks should solve your problem.
You might try looking at this article on the MSDN about using the DesignMode property. This might help you out. You can wrap your code that throws an exception in this in a conditional that avoids the code at design time.
Please note this will not work in the constructor, because the designer has to instantiate the object and then sets the property.
Related
I've gone through multiple resources on trying to find the use cases of when to manually add code to InitializeComponent, but haven't found anything concrete. This suggests we shouldn't do it - The code within the method 'InitializeComponent' is generated by the designer and should not be manually modified
In the past, I had always used the form designer and never needed to manually make changes to InitializeComponent(). However at my new firm, the tech lead has completely ignored the form designer and manually added most UI elements within InitializeComponent (i.e. it has either been heavily edited, or completely re-written to the extent that the Designer can't recreate the GUI in VS, but the GUI is visible and fully functional at when the code is executed)
What is the advantage of not using the form designer? Is it just a matter of preference? Is manually editing/rewriting InitializeComponent for simple UI elements a good practice?
Thanks!
There are only a few reasons why one might need to edit InitializeComponent, such as:
To correct bugs introduced by a bad toolbox item designer.
To remove all traces of a control that cannot be deleted from the VS designer. (This has to be done carefully.)
To make quick "designer friendly" tweaks: changing a property value, adding a property setting, or removing a property setting. When adding a setting, I make sure it looks just like the designer-generated code.
After editing InitializeComponent, I always save & switch back to Designer mode to make sure I didn't break anything.
Any manual initialization code should be added outside InitializeComponent, e.g. OnLoaded() in a WinForms form or user control. As for fixing existing forms, it may be simple or nearly impossible depending on how complicated the form is, especially if controls have been added manually and required initialization methods (such as SuspendLayout, BeginInit) aren't being called.
In the WindowsForms what is the better way to initalize components:
in the properties window?
or in the code (in constructor)?
If I make it in the properties window, then I often have a situation, when I'm changing the value in the code and then closing the form. When I open it again, I'm getting old value (which I've written in properties) and it can confuse.
What is the differences between these two ways? Didn't found it in google.
It's equivalent.
When you change values using the properties window, that values are saved in the resx file. Then the method InitializeComponents(), that is written by the WinForms designed in the Form's constructor, performs the form initialization.
If you do it manually in the constructor, you must place your initialization code, after InitializeComponent() method, then, the form will be initialized with your values.
What method is better? In my opinion, both method are equivalent. You can choose the way you prefer. But my recommendation is not mix them. Use pure Winforms designer or pure code initialization.
I'm experiencing a very nasty with Winforms Designer auto generated code. Sometimes it creates the components variable, and sometimes it doesn't. Even if there ARE components on the form that are designed to be used with an IContainer instance, such as ErrorProvider.
It seems to happens randomly. In this MSDN thread it is suggested to deactivate "Optimized Code Generation" in the designer's options. Unfortunately in my case it doesn't seem to have any effect.
Is anyone else experiencing this? What can be done to ensure that this variable always gets generated when needed?
Several times throughout the course of our current project, the visual studio designer has made modifications that resulted in losing code. For example, event handlers wirings that were set up manually in the designer code were lost. Does anyone know why this happens?
Edit: I understand that editing these files manually is not a good idea, but it has also happened with other event wirings set up through the designer.
Well for starters read the XML at the top of your designer.cs file.
/// <summary>
/// Required method for Designer support - do not modify
/// contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
Generally you shouldn't be modifying these files as they are auto-generated. It's probably the reason why there is a slight attempt to hide the code within a branch, underneath the main partial class.
I have on occasion found that the process has removed its own auto-generated code that I've had to merge back in. Most commonly it decides it's not going to instantiate custom user controls anymore, so when I start running I get a NullReferenceException.
Really the answer is to put the code somewhere else, like in the constructor before calling the InitializeComponent() method. If fellow developers aren't aware of this, then you should inform them and educate them, the fact that the files are .designer.cs should raise questions even to newer developers as to why the strange extension.
You guys aren't modifying generated code files, are you? Like MyForm.Designer.cs? This is why we were given partial classes.
Because it is designer generated and more or less maintained code. It is recommended that you not add or modify code in the designer partial class manually exactly because of the behavior you described (I think it even mentions this in the generated file itself). If you need to wire up event handlers manually then do it in your custom code possibly the constructor of your control.
Write all necessary initialization code only in your own .cs file, you have number of places to do this, like form constructor and form Load event handler.
Moving the designer code into user maintained code classes defeats the benefits of being able to modify the user interface. Perhaps this might be something you would want to do if the program never needs to be modified again, but if that is the case... where is the benefit as well?
This issue of the designer class losing lines of code has existed since Visual Studio was initially released and has caused me countless nightmares because the loss occurred perhaps weeks before, when the program was previously modified.
I can't prove it but it seems obvious that something in Microsoft's code generator is failing and there isn't any alerts to tell you it crashed. So, Microsoft... fix what is crashing or at least, tell us about it when it happens.
I've seen multiple posts and questions about the DesignMode property of Forms and UserControls. The idea is that you want to check if the control is in design mode (e.g. the control is shown in the Visual Studio Designer), and avoid code that can only be run in, well, run-time.
The problem I've seen many have - and my failing memory exposed me to it too, recently - is that the DesignMode property does not work in the constructor, and does not work for the nested controls.
However, it works extremely well in the Load event handler for your control or form!!
When you think about it, the code in the constructors of the Forms or UserControls should only deal with state that does not require the form to be loaded.
Code dealing with UI objects initialization should maybe be located in the Load event handler for the control. And in that function, the DesignMode property works. The Designer will use its proper value at that time.
In principle, the InitializeComponent() method has been called but in reality, when you show the control in Design view, the Designer only parses that function, it does not run it. The Designer, however, does run the constructor of nested controls.
If you absolutely need to put initialization code in the constructor, use theSystem.ComponentModel.LicenseManager class, it has a static property called UsageMode which takes values of DesignTime or RunTime. You can absolutely trust that property in the constructor of your control - but in the constructor only!
I had forgotten that little subtlety in the app I am working on at the moment. To get around the issue, I am adhering now to the pattern that all controls and forms which need extra initialization must implement a handler for the Load event. There, the DesignMode property works just fine, and I never have trouble opening my user control and forms in the Designer.
If I have a class hierarchy, I sometimes make that event handler virtual protected, and I only override it when the subclass needs extra initialization.
I am wondering, though, if there are better methods out there, or if there is something smelly about this pattern (other that having to implement a Load event handler many times?)
Because of the issues with using the DesignMode property with nested controls (and related problems), my general approach to this problem is to not even try to get my custom UserControls to function in design mode. Usually my controls are very complicated and owner-drawn, so even if the DesignMode worked with nested controls, it would take a great deal of programming effort to get them to show anything meaningful in design mode (and it would slow down development work, because the controls require a significant amount of initialization and setup time).
Usually I just add a public Setup() or LoadData() method that does all the work, and only call this method at runtime. In design mode, then, the UserControl just shows up as a square, which helps me position it and nothing more.
I'm interested in seeing if you get any other answers to this question, however, that might address your problems.