As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
One of the most loved and hated feautures of visual studio must be the form designer.
Creating a simple form/user control layout usually is a breeze. Setting properties and adding events is easy.
Setting up the toolbox to use you own controls can be a bit harder and getting the ToolBoxIcons to show up can be a pain. Using third party components by visual inheritance can throw of the designer. And using multiple inheritance on designerables can be really hard.
So what are your favorite 'hidden' and or obvious visual studio designer features.
Hold down CTRL and drag a control to duplicate it.
NOTE: Be careful, if your control has
an event handler that was created by
the designer, it will associate your
newly created control with the event
handler as well as the old control.
Use the keyboard shortcut F7 to go from the designer view to the code view, and Shift-F7 to go from the code view to the designer view. I use this constantly
The "Document Outline" window is essential for heavy designer use. This allows you to reorder the controls in the outline to bring them to the front or send to back. It's especially useful when you're working with docking controls. You can also move a child control to a different parent, or take it out of a container control, or move a parent into a container, etc...
View -> Other Windows -> Document Outline
The "Layout" toolbar is great for lining things up to make a clean looking user interface.
View -> Toolbars -> Layout
When the WinForms project designer is open on a form or user control and you have nested child controls, you can move the focus off of the currently focused child control to its parent control by pressing the Escape key. Pressing the Escape key again moves focus to its parent and so on until you finally reach the top.
Did you know you can actually debug the designer?
You can start up a single solution twice and use 'Attach to process' to debug a devenv environment running your designer controls. This can be especially helpfull to debug 'strange' designer problems that give very little information otherwise.
I used this to pinpoint a designer problem to some remoting that got started and didn't work triggering an unhandled exception and breaking the designer. All I saw at the desigerview was some visual studio internal helper classes crashing.
You can add your own snaplines to UserControls.
The class below here is called CenterSquare, and has a Designer added to it called CenterSquareSnapLines that supplies a list of snaplines inside the control. If you've got your own controls that render smaller then just their borders you can now add your own snaplines.
public class CenterSquareSnapLines : ControlDesigner
{
public override System.Collections.IList SnapLines
{
get
{
ArrayList snapLines = base.SnapLines as ArrayList;
CenterSquare c = this.Control as CenterSquare;
if (c != null)
{
snapLines.Add(new SnapLine(SnapLineType.Left, c.BorderDistance));
snapLines.Add(new SnapLine(SnapLineType.Right, c.Height - c.BorderDistance));
snapLines.Add(new SnapLine(SnapLineType.Top, c.BorderDistance));
snapLines.Add(new SnapLine(SnapLineType.Bottom, c.Width - c.BorderDistance));
snapLines.Add(new SnapLine(SnapLineType.Top, 5));
}
else
{
//Debug message here!
}
return snapLines;
}
}
}
[Designer(typeof(CenterSquareSnapLines))]
public partial class CenterSquare : UserControl
{
//implementation goes here
}
I try to code my own event handler methods when forms initializes instead of letting the designer take care of it. I have noticed that the designer will lose these events from time to time. By coding your own you make sure they stick.
myButton.Click += new System.EventHandler(this.myButtonClick)
All properties on user controls will be shown by the designer and filled with default values for datatype.
Adding the DesignerSerializationVisibility attribute with Hidden as a value will not fill this property with any default values.
<DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)>
This is a great way to keep the amound of designer code to a minimum. Another option is DefaultValue.
<DefaultValue(somevalue)>
This will set the designer to use the given value as a default value for the selection.
The designer will override backing field values and initializer values if you do not use these attributes.
Another one that can be hard to find:
Menu - View - Tab Order
You can change the tab order by clicking your fields. This option is only visible while the designer is active.
Broken designer:
Sometimes visual studio won't show the switch to Designer/Code option. I haven't nailed down what causes this exactly but mixing vb.net and c# projects while using devexpress seems to be a reason.
As long as visual studio runs it won't suddenly see that my forms/usercontrols can be designed. Closing down visual studio and changing the project file usually helps.
Originally the project file contained
<Compile Include="cboTargetGroupFlights.cs">
Changing that to and reopening the project caused visual studio to recheck all forms/usercontrols and did show the designer again.
<Compile Include="cboTargetGroupFlights.cs">
<SubType>Component</SubType>
</Compile>
Did you know you can set the code view as default after double clicking something in the solution view. Right click you file and choose Open with... and use the Set as Defaults button.
Related
I have made a FormBase, from which I inherit a FomBaseList and a FormBaseDetail.
All other forms in the project are derived from FormBaseList or FormBaseDetail.
Now it seems that VS has huge problems with that, and my biggest problem is that VS keeps writing property values from the Ancestor form into the designer.cs from the child form.
for example, in FormBaseList I have this property/value :
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = true;
I expect that in a derived form, for example FormClientList, there is no mention for this value in the designer.cs, because it should fetch the value from its parent. In other words, just plain simple basic OOP.
And I also expect that when I change the property in FormClientList to
this.gttDXGridView1.OptionsView.ShowAutoFilterRow = false;
that this is seen as an override from the baseclass.
However, VS keeps overwriting the property in FormClientList.Designer.cs with the value found in FormBaseList.Designer.cs.
This breaks the rules of OOP in my opinion, other tools that support Visual Inheritance like Delphi for example do this correct.
How can I stop VS from doing this ?
The properties are changed using the designer.
All controls are DevExpress controls, or derived from a DevExpress control.
Another example, which works just opposite so its very strange.
For example put a Button on the BaseForm and give it an image.
The button with the image appears on all derived forms.
Now change the image on the button of the BaseForm.
You would expect the image to change on all derived forms also, but that does not happen.
I discovered that again VS has written the property value of the button in all derived designer.cs files, and this time it does not overwrites them.
I created a ticket about this at the DevExpress forum, and they where able to reproduce it.
It is now passed on to their developers.
https://www.devexpress.com/Support/Center/Question/Details/T692940/devexpress-controls-break-visual-inheritance-in-visual-studio
It also seems I was not the first to report a similar problem.
https://www.devexpress.com/Support/Center/Question/Details/T692244/imageoptions-are-serialized-in-a-successor-when-visual-inheritance-is-in-effect
I downloaded a project off codeproject and was messing around with it (I am more an asp.net developer) when I noticed these overlay icons...the lock one on the label is really interesting as when I right click the control is unlocked yet all the properties are grayed out. When I add a new label I do not have that lock icon when I select it. What is this? Also what is the double boxes icon (the other 8 that are highlighted)?
The Winforms designer observes standard .NET accessibility keywords. The Modifiers keyword for a control is what counts here. That sets the access keyword for the member variable. The default for a C# project is private, for a VB.NET project it is Friend. VB.NET is more friendly about it.
That matters when you derive a form from a base form, Project + Add New Item, Windows Forms node, Inherited Form item template. The derived form will have the controls of the base form but they cannot be changed if their Modifiers property is Private. The designer makes it obvious by displaying the lock icon. And by displaying the properties of the control in gray text.
Normally this means that the controls are defined in the base control and so you cannot change them in the derived control (so they are all locked).
I’ve met strange behaviour for WPF design-time in Visual Studio 2010: after an instance of the Popup class was created, and I switched the code tab in Visual Studio to a different file, the Popup still remains on the screen!
I have a piece of code, which allows to reproduce this, but I am not sure if I should paste it here (it's not so short), so maybe I'll just give a link to it: here.
For unknown reasons beyond mere mortals' comprehension, Microsoft has decided this is the default behavior of the Popup class in WPF. You have to implement the "hiding" logic yourself. I suggest handling the Window.LocationChanged, Window.Activated and Window.Deactivated events of the Window containing the Popup and close it yourself.
Edit: To clarify myself, the Window events you need to handle are the events of the window that contains the Popup's PlacementTarget element. Usually when you create a popup, you set it relative to some element contained in an application's Window (similar to how the tooltips work). If this is your case, then my solution is correct, but I forgot to mention this point about the PlacementTarget.
In your code behind; you can simple check this boolean:
DesignerProperties.GetIsInDesignMode(this);
"this" represent the object containing the popup. For example the Window.
If true you can say:
myPopUp.IsOpen = false;
For Store Apps/WinRT:
Windows.ApplicationModel.DesignMode.DesignModeEnabled
I am experiencing some very strange behavior with Blend:
Since weeks i am working an a project where I use Blend 4 and Visual Studio 2010 simultaneously. I've never experienced problems with one of these programs or with their co-existence. Work proceeds fine.
But a few minutes ago - from one boot of the computer to the next - Blend seems to have a serious problem:
From now on I am not able alter any value anywhere in my project. I can't create new Controls on a plain surface as well delete existing ones. If i try to alter some attribute of some existing control, the width of an existing button for example nothing happens:
Drag and Drop with the mouse results in nothing more than a slight flickering of the control which looks like if it is fighting against my modification to retain its current value. Regardless what manipulation I apply with the mouse the control stays untouched neither does any value in the properties-panel of Blend change.
It feels as if my project is in read-only mode or locked somehow.
But now comes the frustrating fact: When I apply the modifications described above nothing changes BUT the corresponding XAML code does! Enlarging the width of a button with the mouse doesn't show any effect at the control itself or in the properties pane but the XAML attribute width is changing as I move the mouse ?!
Did anybody also experience this behavior before ? Does anyone has some suggestions ? Maybe the solution is very obvious and just made a fool of myself but I got really stuck with that problem - so any help or suggestions are very much appreciated ... Thanks in advance !
EDIT: It really seems to be a Blend problem because when I open the project in Visual Studio everything is working as it should ...
Are you certain that there is not a control sitting on top of the others?
Alternatively, are your other controls in a panel (perhaps a grid) that has it's visibility set in a trigger? If so, Visual Studio displays controls visibility a little differently than Blend does. Blend attempts to get the property to which you bound your visibility during design time, whereas Visual Studio seems to display the item so long as you have visibility initially set to visible.
Can we see some code to make sure?
I have a very strange issue and am not sure why it is happening or how to prevent it.
Envionment:
.NET Framework 3.5
WinForm application
C#
VS2008 Pro
Issue:
I have a WinForm containing a TabControl which has a custom usercontrol on two of its TabPage.
The usercontrol i created contains 3 DataGridView controls.
Everytime I go into Desiger of my WinForm, I see that there are SIX (3 * 2) instances of a DataGridView control created.
They are all numbered such as dataGridView13, dataGridView14, etc...
Along each of those DataGridView instances, the associated DataGridViewTextBoxColumn and DataGridViewCellStyle instances are also created.
Pretty soon I had nearly 600 DataGridView instances in the MyWinForm.Designer.cs file!!
Why is this happening and more importantly how to prevent it???
Anyone has seen something like this before??
The designer in Visual Studio has problems handling inherited controls, especially so with the DataGridView control. If it is also a container for child controls, like columns, a new set of children will be generated every time you save a modification.
The only way I have found to address the problem is to make your modifications, save them, then remove the previous list of duplicated controls. The designer at least has the courtesy to number them sequentially by type of control.
Oh, and save yourself the frustration of renaming any of the controls. When the designer generates the new set, it reverts to its default naming practices.
Sorry I don't have better news for you.