I tried to create a custom user control in C# that handles other controls that are added to it. The custom control consists of two panels. What I'm trying to achieve is, that if another control is dragged to my user control in design mode (or added programmatically at runtime) I want that control to be placed on one of the panels.
I tried to handle the OnControlAdded event but that didn't do the trick...
Markus wrote : "if another control is dragged to my user control in design mode (or added programmatically at runtime) I want that control to be placed on one of the panels."
I am going to interpret the above as meaning you want the Design-Time dragged control to become a child control of one of the two internal Panels of your UserControl : if that intrepretation is wrong : please disregard what follows :)
Also, just to avoid confusion : you are absolutely correct when you observe that Panels, or other "container" Controls, in an instance of a UserControl placed on a Form at Design-Time, do not "consume" or "swallow" dragged over controls as you might expect : in fact you can't even select them individually : they are added to the UserControl's ControlCollection.
Fortunately for you, in the design-time drag-drop case there is a good solid code example you can study and use on CodeProject by Henry Minute : Designing Nested Controls : that article will show you how to inherit from ParentControlDesigner so that child controls which are containers of a UserControl at design-time can function as containers in the way you are looking for.
In the case of your wanting the consumer of your control at run-time (programmer) ... assuming they don't have source, so they interact with your UserControl as a "black box," able to "see" only Properties, and Methods, available Events, etc., you've made Public ... to control where an added Control is placed : you have a decision to make about how you wish the consumer to access the Panels. You could expose them "directly" as objects, via Public Properties of the UserControl, or you could expose only a Public method for adding controls for each panel.
Why not just drag it into the panel, or give one of the panels a public accessor and do all your programmatic adding to that panel directly?
Related
I'm not very clear of when to use a CustomControl and when to use an UserControl. I basically know what CustomControl allow(more customization when using with template).
I want to make a "File browse" control in WPF(TextBlock that displays the current path + Button that trigger a "Open File Dialog").
I'm not sure, because at some places I find that they say this should always "replace" a WPF control. I was more thinking that a a CustomControl was more like a way to display and edit one new semantic value (in my case, a "File(path)").
So, if we don't take into account which one is easier to do, what would be the more adequate between CustomControl and UserControl for the "FileBrowse" control that I'm speaking about?
Thank you
Custom Control:
A loosely coupled control w.r.t code and UI
Derives from Control
Defines UI in a ResourceDictionary
UI can be changed in different projects
Has full toolbox support
Defines a single control
More flexible
User Control :
A tightly coupled control w.r.t code and UI
Derives from UserControl
Defines UI as normal XAML
UI is fixed and can't have different looks in different project
Can't be added to the toolbox
Defines a set of controls
Not very flexible like a Custom Control
When we talk about differences, it is more important to emphasis on the context when to use what:
When you have a rapid and fixed content in your UI, use UserControl.
When you want to separate some basic functionality of your main view to some smaller pieces with reusability, use UserControl.
When you want to use your control in different projects and each project may want to change the look, use CustomControl.
When you want to implement some additional functionality for a control, create a CustomControl derived from the base control.
When you want to apply themes to your controls, use CustomControl.
When you want to add toolbox support for your control, so that your user will be able to do drag and drop to the designer, use CustomControl.
I think a UserControl is the one to choose, for it is used for a kind of "assembly of existing controls". In your case a button and a file open dialog. It will then get a specific look and feel (for example the default look of a button and the default look of a file open dialog).
The CustomControl is kind of the other way round. It has no look and feel by itself. It is completely abstract concerning layout. The layout comes into play, wwhen assigning a style to it.
In general a custom control extends an existing control while a user control creates a new control type from a collection of existing controls. I would say that a user control is better suited, based on the information you've given.
Could someone please tell me the differences between using a Form, Panel or a UserControl.
A form is a control and a container for other controls. A form is the base unit of a windows application.
A panel is a control and a container for other controls.
A usercontrol is a user defined control.
See:
Windows Forms
Windows Forms Controls
Windows Forms Overview
In Windows Forms, a form is a visual
surface on which you display
information to the user. You
ordinarily build Windows Forms
applications by adding controls to
forms and developing responses to user
actions, such as mouse clicks or key
presses. A control is a discrete user
interface (UI) element that displays
data or accepts data input.
When a user does something to your
form or one of its controls, the
action generates an event. Your
application reacts to these events by
using code, and processes the events
when they occur. For more information,
see Creating Event Handlers in Windows
Forms.
According to MSDN the Panel class is "Used to group collections of controls", while the User Control "Provides an empty control that can be used to create other controls".
You are right: this doesn't help you a lot to decide whether you should use a Panel or a User Control.
One of the differences is that a Panel is a ScrollableControl, while a UserControl is a ContainerControl (which is also a ScrollableControl). So if you want ContainerControl functionality, consider to use a UserControl.
You'll probably don't know what a ContainerControl does, so what you can't do with a Panel, hence the following might be more useful:
In object oriented programming, and so also in Winforms, whenever you want a class that behaves like another class, but only slightly different, you consider to derive from the other class.
So if you want a button that changes color when pressed, and returns to its original color when pressed again, (like an on-off button), you might consider to derive from class Button, or maybe from class CheckBox-in-the-shape-of-a-button.
By making it a separate class, you can reuse the code in similar situations. Whenever you will only use it once, then usually we won't bother to make it a special class. We will usually not make a special class for "The Select button in my form, which does ... when clicked", but if you will use this button in ten different forms, then it is probably wiser to create a SelectButton class.
Similar, if you have a group of controls, with some behaviour, and you plan to use that in different forms, consider to create a User Control, where you put this behaviour. The nice thing is that the code of this behaviour is hidden inside the control. Users of your UserControl only have to know what it does, not how this is done. You might even want to hide how this is done, so users (= code, not operators) can't access it
A panel is more or less like a GroupBox without a surrounding rectangle: consider to use it instead of a User Control if you will be using it only inside this Form. Similar to how you would us a "Button that does ... when clicked": because you use it only here, you don't derive from it.
I seldom use a Panel. The derived classes: TabPage, SplitterPanel, ... are more likely to be used only in this form.
Whenever I need combinations of several controls, especially if they interact with each other. For instance, if you have a text box and a label that describes what is in the textbox and an OK button that processes the text in the text box. In that case I usually make it a UserControl.
I could have derived from a Panel and add a Label, TextBox and Button, but then users could mess up with my Panel by adding other items, or calling Panel functions that would mess with my functionality.
Come to think of it: using a class derived from a Panel vs using a UserControl is similar to deriving vs aggregation / composition: If you aggregate, you can limit access to functionality, if you derive, users can access all parent functionality.
So if you only want limited functionality: show / no show, maybe size and position, background, but not much more: consider to create a UserControl. If you want the possibility to change the behaviour, consider to use a Panel, especially if you will use it in only one form.
I need to implement TabControl-like behaviour with manual (on event, on a button click for example) pages switching and having all pages designed and implemented as separate forms. A form to be incorporated (as a panel control) inside main form and replaced by another form as needed.
How to achieve this?
PS: The reason why I don't want to use TabControl instead is because there are going to be too many tabs - I'd prefer to present the list of them as a TreeView and instantiate on demand. The another reason comes from another project of mine - there I am going to implement plug-ins, where a panel inside main window will be provided by a class loaded dynamically and will be runtime-switchable.
I need to implement TabControl-like behaviour with manual (on event, on a button click for example) pages switching and having all pages designed and implemented as separate forms
May I ask why this is a requirement? It seems like the logical approach would be to create a set of UserControls. You can place a UserControl in a form, and you can place a UserControl in a tab. You get modularity without the headache of implementing a very odd requirement which is a use case that the API developers obviously did not think was valid. I just can't think of a good reason to take the route you have suggested.
I did similar thing once, and for that reason, I have ReplaceControl method, which I paste below:
static public void ReplaceControl(Control ToReplace, Form ReplaceWith) {
ReplaceWith.TopLevel=false;
ReplaceWith.FormBorderStyle=FormBorderStyle.None;
ReplaceWith.Show();
ReplaceWith.Anchor=ToReplace.Anchor;
ReplaceWith.Dock=ToReplace.Dock;
ReplaceWith.Font=ToReplace.Font;
ReplaceWith.Size=ToReplace.Size;
ReplaceWith.Location=ToReplace.Location;
ToReplace.Parent.Controls.Add(ReplaceWith);
ToReplace.Visible=false;
}
Only thing left to do is to create some control manually on the form, as the placeholder for your Form. Use label, for example.
You could do this with an MDIForm as the main form, and then plain-old Forms as the separate forms. Or you could encapsulate each element's functionality as a UserControl which you can then swap out on your form in code.
The advantage of encapsulating your UI elements as UserControls is that if, for whatever reason, you need them to become forms in your application, you can just drop the UserControl on a form.
Update: Since you want to use a TreeView to select what the user is looking at, you definitely want to do this as a bunch of UserControls. The layout is simple: TreeView on the left, and whichever control is active on the right.
There's no need to justify not using a TabControl - tabs are the worst UI element in history.
I have a WinForms user control Host with a custom UI Editor.
Through that editor, a child control (Child) can be added to Host.
(The UI Editor creates Child and sets Child.Parent = Host)
Child is handled through a Holder<Child> helper class, which is set as Tag property of e.g. a ListViewItem.
The respective code - some of it, at least - gets added to the form: Holder is created, and set as Tag, which is enough to be created at runtime, too.
However, Child is not visible to the designer - it is displayed, but it can't be selected, nor does it occur in the drop down list with controls for the parent form.
I would like to:
see the Child control in the designer, so that I can modify properties
get notified if the control is removed
Is this possible?
[edit] Thanks all for your input. I've decided to skip the designer - I hoped to throw together something quickly, but apparently it requires more planning than I should allow myself to spend on it right now.
Usethis.Controls.Add(/*Instance of the child*/); on the host class. Then for the notification add event handler for the host's ControlRemoved event (this.ControlRemoved += new ControlEventHandler(Host_ControlRemoved);).
I can't say I fully understand exactly what you are trying to do.
If you are dealing with the problem of how a "child" Control of a UserControl placed on a Form at Design-Time can be made to function as a container onto which you can drag-and-drop other controls from the Toolbox : this CodeProject article by Henry Minute may be helpful : Designing Nested Controls. For example : you have a UserControl with a Panel inside it : an instance of the UserControl is placed on a Form : in the Design-time view of the Form : you want to be able to drag-drop controls onto the Panel in the UserControl and have them become child controls of the Panel : Henry's article will show you how to do that.
This from Microsoft : How to make a UserControl object acts as a control container design-time by using Visual C#
Perhaps might also be useful, although it seems like you already have this step accomplished.
I've created a control class that inherits a Panel control. This control then contains two other panels, one of which I would like to be an IContainerControl.
I know how to turn the entire control into a IContainerControl but have been unable to do the same to a child control. I've tried in both C# and VB.Net and failed with both.
Does that make sense? I tried searching but didn't find anything that helped, hopefully someone here can get me on my way!
Thanks!
edit
I'm sorry, been a long day... I'm using WinForms.
Basically I need a custom usercontrol that has two panels, one that displays some stats and the other that contains controls. The stats panel is done and working, but the other panel may contain a DataGridView, a ListView or a TreeView (whichever the user adds at design time).
And yes, I've implemented both ActiveControl and ActivateControl.
I think you have two strategies here : first the "cheap stuff" :)
Cheap stuff strategy :
assuming the end-user is a programmer with source, with the project open in Visual Studio or Mono, able to create UserControls, and able to drag-drop their choice of controls (such as the Treeview, or ListView, you mention) onto "whatever."
a. create two UserControls
b. UserControl1 contains room for two panels.
c. on one side of UserControl1 insert a Panel, and design it to spec.
d. on UserControl2 : allow the end-user to insert the control of their choice : TreeView, etc.
e. build both UserControls
f. place an instance of UserControl2 (from the ToolBox icon) onto UserControl1 and position it (Dock, Anchor, whatever) as you wish.
Build again. Now you can place an instance of UserControl1 on a WinForm, and it will include both Panels.
Costs/Benefits :
you can edit the appearance and properties of each control in the standard way
the end-user can choose which Control to go on UserControl2.
you've got a greater separation of components here that may allow greater ease of maintenance or extension ?
who's going to do the programming based on whether the user chose a TreeView or a ListView for the Control to go on UserControl2 ?
More Expensive Stragegy
You are going to need to get into inheriting from 'ParentControlDesigner to make a run-time placed control that is a container placed inside another container accept design-time drag-drop of controls.
Fortunately, there's a good article by Henry Minute on CodeProject with C# source : Designing Nested Controls Strongly suggest you read the comments by Sacha Barber at the bottom of this article and the answers by Henry Minute.
And also see, here on SO : Adding design-time support for a nested container in a custom/usercontrol (Winforms).
In either strategy you'll have some work to do to enable access (what properties you expose, what events you raise "up" to enclosing containers, etc.).