I have a project with 100's of usercontrols. When I load the project in VS2010 and try to open a designer, the toolbox spins and spins until they're all loaded.
Winforms has a "AutoToolboxPopulate" switch under Tools/Options/Winddows Forms Designer/General.
I cannot find a similar switch for the XAML designer. Does one exist?
In VS2010, the Auto Populate Toolbox switch for XAML can be found under Tools/Options/Text Editor/XAML/Miscellaneous.
If you wish to keep the Auto Populate enabled, you can decorate your usercontrol classes with the System.ComponentModel.DesignTimeVisibleAttribute which will allow you to specify if they appear or not in the designer.
Unfortunately there isn't one that I am aware of, with the exception of actually adding a design-time (*.Design.dll) assembly for the project that effectively defines metadata to hide the explicit controls.
This bit me as well recently and I wish I had a solution like the old winforms attribute!
Related
Must every control in the Visual Studio WinForms toolbox descend from Control?
Does Visual Studio support window-less controls?
Every control you add to the Toolbox in Visual Studio:
must1 descend from Control, which is a wrapper around a windowed control.
Unfortunately, Windowed controls are very "heavy"; having a lot of them, especially nested, causes performance in WinForms to suffer.
In the past i've dealt with the problem by creating aggregate custom controls. The custom control internally contains other window-less controls:
an image (windowless version of a PictureBox)
title label (windowless version of a Label)
subtitle label (windowless version of a Label)
border (windowless version of a Panel)
These are useful to mitigate performance problems in WinForms, but they're stuck inside code.
i would like to do what other development environments allow, is a version of Control that doesn't create a Windows window. i would like the ability for the Visual Studio toolbox to accept **window-less* controls.
i know that if i really wanted window-less controls: i should switch to WPF. But that's overkill.
Does Visual Studio WinForms support window-less controls?
1 or not
Yes and No.
First, check out this article from the venerable Raymond Chen: http://blogs.msdn.com/b/oldnewthing/archive/2005/02/11/371042.aspx
Yes. You are welcome to create "controls" that do not derive from Control. I have created several windowless controls in my application that natively support clicking, layering, etc., I draw them to an offscreen buffer, and then paint them directly on some parent Form or Control (such as a PictureBox). This is straightforward to do but not simple, as you will need to manage everything yourself in code.
No. Any windowless controls will not be supported in the Windows Forms designer for any of the Control-derived controls designers (such as placing them on a Panel or Form) so you won't have drag-and-drop form design.
As Hans has pointed out, the ToolStrip and MenuStrip (a windowless control) are such examples. Notice that when you create a new MenuStrip on a Form, the MenuStrip is placed in the Component tray underneath the form. The MenuStrip has a custom set of Designer classes associated with it to support the custom painting and "Type Here" functionality, as well as the dialog boxes to add and remove menu items. Note that the "child" windowless controls, such as the ToolStripButton, are not available in the ToolBox for drag-and-drop support directly onto the form - only the custom designer knows about it. The custom designer for the MenuStrip also supports selecting the child windowless controls so that you can edit the properties of each item in the Properties window.
I can't imagine this is suitable for your situation (unless you are creating some controls for resale), but if you are very determined, you can create designer support in much the same way for your set of windowless controls:
Create a class that derives from Component that will be used to manage your Windowless controls. For example, you could call this class WindowlessWidgetManager. After you compile, this control will be in your toolbox. The WindowlessWidgetManager can contain a collection of your windowless controls, and provide painting and other UI support for a canvas such as a Form or PictureBox.
Create a designer class that derives from ComponentDesigner that supports things such adding and removing your custom controls at design time. For more information, see http://msdn.microsoft.com/en-us/library/system.componentmodel.design.componentdesigner(v=VS.90).aspx
This is a very lengthy process with a number of caveats, but if that is what you wish to achieve, the functionality is there.
If I create a WPF user control, it appears automatically in the Visual Studio toolbox.
Is there a way to make other controls appear automatically in the Visual Studio toolbox?
Conversely, is there a way to hide a user control from the toolbox?
You can right click on the toolbox and select Choose Items... Then from there you will get a dialog that allows you to select which controls to show or hide.
Per comment below if you are trying to figure out how to do this for a Third Party that you are providing your control to check out this MSDN article that describes packaging your control:
http://msdn.microsoft.com/en-us/library/ms165358.aspx
Auto population is described here (at the end), but to summarize you can add DesignTimeVisible(false) to your UserControl to prevent it from being added to the Toolbox.
Your controls should be added just like your UserControls, assuming they meet the requirements at the end of the link above, which are:
To appear in the Auto-Population
Toolbox process a type must derive
from FrameworkElement and:
Are public and have a default public or internal constructor or are
internal and have either a default
public or internal constructor
Types deriving from Window or Page are ignored
FrameworkElements in other .exe projects are ignore
Internal classes will only be displayed when the active designer is
for an item in the same project
Friend Assemblies are not taken into account for Toolbox
Auto-Population
If you are building reusable controls (where your end-users will simply add a reference to your assembly), then you'd need to tell Visual Studio that it should load your controls into the Toolbox. There is a tutorial for WinForms controls on doing this here, but the concepts are the same. A VSIX installer tutorial can be found here.
A lot of the resources out there are for older versions of Visual Studio, but again the same concepts should apply. You simply need to update version information where appropriate.
Is it possible to have a project containing both Winforms and WPF?
Say a WinForm project that is transformed step by step(form by form) in a WPF one, will be possible to have a Winform opening on a button, and a WPF one opening on a other button?
Yes. You have to pick one technology to display each physical window and control in your app, but there's no reason why you can't mix and match.
For example:
A WinForms window can show a WPF window.
A WPF window can show a WinForms window.
A WinForms window can contain WPF content (see the ElementHost control).
A WPF window can contain WinForms controls (see the WindowsFormsHost control).
This works great.
One can have WPF windows in Windows Forms and Windows Forms windows in WPF
http://msdn.microsoft.com/en-us/library/ms745781.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.windowsformshost.aspx
Adding Winforms to WPF projects can be done smoothly (directly from the "Add new item" menu), but there is not straight option to add a WPF window to a Winforms project. Still, I handled to do it following these steps:
Add a WPF User Control (this option is available on the "Add new
item" menu) and then convert it into a WPF Window. Modify the XAML
changing the UserControl parent tag to Window, and remove the
inheritance from UserControl (all of this is explained in this link).
Add a reference to System.Xaml.dll. See this link.
Add a reference to System.Windows.dll (I found it on my computer on this path: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5. Be aware it might be different in yours). See this link.
What you might be looking for is the ElementHost control. What it lets you do is take WPF content and host it in a Windows Forms window. More details are here:
http://msdn.microsoft.com/en-us/library/ms745781.aspx
There is also a control that lets you do the reverse: host Windows Forms content from within WPF:
http://nayyeri.net/host-windows-forms-controls-in-wpf
Between the two, you can move the 'dividing line' between WPF and Windows Forms with some degree of flexibility.
There is at one caveat you'll need to keep in mind. Windows Forms works internally in terms of HWND's... a window managed by the legacy Windows window manager (which handles the z-order). WPF doesn't do this... A WPF tree is typically rendered into a single HWND', and it's WPF that manages things like z-order. What this means to you is that z-order doesn't always work the way you expect it to, and there are things you can't do with hosted Windows Forms controls that you can do with traditional WPF elements. (There is actually a way to solve this, but it involves periodically rendering the HWND into a memory bitmap, rendering that bitmap into a WPF surface, and then redirecting events directed to the WPF surface to the underlying HWND. This is powerful, but tricky and difficult to get right.)
I see no objection to do that.(I have in WinForms Application WPF windows)
Many of the examples used MessageBox.Show which is part of the Windows.Forms.
Of course you must rewrite all windows, not only controls.
I am working on a Visual studio like application i.e. have a toolbox, an editor and property grid similar to VS.
User can drag and drop the controls(custom and third party) to the editor window and perform operations like resize, move, align, group etc.; Properties of that control needs to be displayed in property grid and user can update them from there.
As per my current understanding I will have to extend the Canvas to create my own editor and and Interface for controls which it supports; Each supported control will have to implement this interface so that it can be placed in our editor.
Something similar to this - http://www.codeproject.com/KB/WPF/WPFDiagramDesigner_Part4.aspx
Looking forward for any kind of help, comment or links.
If WPF is a requirement, wait for the VS2010 release and use the Visual Studio Shell in either isolated mode or integrated mode. Otherwise you can use the Visual Studio 2008 Shell isolated or integrated.
You'll get the docking support, addin model, editors with highlight and much more almost for free that way.
Finally, I used the Diagram designer approch to build my application. Although, I had to create my custom property grid which was painful.
Recently I came across following post which suggests that .Net DesignSurface can be used for building this kind of application -
How to create an UI Designer utility?
I have been working on a generic framework Wide to create VS like applications.
Update: Here is the CodeProject article on how to use the framework.
Wide comes with two modules and various out of the box functions:
Core module (Required)
Used for customizable splash screen
Used for Menus (supports regular menus with icon, checkable menus)
Used for Toolbar (menu view model can be reused for toolbars)
Multiple toolbars can be added to the IDE (check demo)
Themes (VS2010, VS2012 Light theme and no theme)
ThemeManager to add/remove themes
Used for Statusbar (in development)
Open file service with participatory handlers (could be based on extension or even file contents)
Save and restore layout along with opening documents
Logger module (For the logging tool)
I'm building custom control for my Silverlight 2 app. It's in one SL class project, and it contains two files:
MyControl class, inherited from Control, with few DepedencyProperties
themes/generic.xaml, with visual elements (ControlTemplate), states for VSM and transitions
I created whole xaml by hand, and it works, but want to use Blend2(SP1) for editing! When i open generic.xaml in Blend, and switch to Resources tab I don't have anything to edit.
For example, when I put that visual template and states definition to App.xaml (of my main SL project), I can access all elements and States through Resources and States tabs, and edit them visually.
Does Blend even support editing generic.xaml from SL2 class project?
What's the best practice for building custom controls? I don't want to my custom control depends on anything from main SL2 project, but want them to be skinnable, and be able to change skins (themes) dynamically.
You can edit this with Blend.
Open your controls project in Blend.
Open your generic.xaml
click the Resources tab
Expand generic.xaml
Double click the style resource you want to edit.
In the Objects and Timeline section, right click the Style and select "Edit Control Parts -> Edit Template"
Now you can edit the template in the generic.xaml. Sounds like you're already following best practices by having the parts and states. If you want the full blown best practices take a look at this detailed post on how to deal with design time extensibility. There you will find out how to do the Visual Studio and Blend design time stuff for Silverlight.
I recreated whole project, and suddenly can edit my generic.xaml from Resources. But can't add news stated in Blend, for that I must go to xaml.