Looking for guidance in creating a address control C# - c#

I am looking to create an application that will query for address information (first, last, address, city, state, zip). A custom Address Windows control you can use in any application. This control needs to validate zip code and that all fields are properly filled in. I am looking for some tutorials that can help or any guidance On how to create this type of control.

You should consider creating an Address model class that defines the data you are collecting. Individual properties of the class can be bound to the values of controls in your usercontrol gui.
This class can implement the INotifyPropertyChanged and IDataErrorInfo interfaces to help it interact with the windows forms data binding components.

Like #Francesco suggests create a user control. It is essentially a compound or composite control. For address you can add the required text and label controls and maybe the logic to validate them. Then you can reuse this across projects.
Add a class into your windows forms project like this:
public class AddressForm : UserControl
{
//excluding this causes probs with VS designer sometimes.
public AddressForm() : base()
{
}
}
Build your project and you will notice the file icon in visual studio changes, when you double click it you can then design the control by adding simple controls on it.
Make sure you build after any change, and you should also see the toolbox updated when you're designing a form. AddressForm will show up there and you can drag and add it on the form. It is now officially reusable.
See msdn on UserControls for more. Try and run their customer form sample (on the same page) and you should have a good idea.

Related

WPF: Create a UserControl or a CustomControl?

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.

Why do we need UserControl ? It seams that a Custom Control can do all the things that UserControl can do. WPF & Windows Store App [duplicate]

I've been reading some explanations about the difference between User and Custom Controls, for example this:
http://www.wpftutorial.net/CustomVsUserControl.html
I want to create, for example, a simple composition of a datagrid with 2 comboboxes which are responsible to change the values from the datagrid's items. I want to create a specific control for this because I'm going to use it a lot of times. I would like to implement the logic behind and then in the xaml invocation I only have to specify the itemsSource.
For this example should I create a User or Custom control? Since I will have properties and logic, should I have a viewmodel for this control?
EDIT: Do you know some articles with clear conceptual separation between these 2 options?
Choice is not only between user control and custom control, but among user control, custom control, customizing control template, customizing data template, header template (for collection based controls), attached properties.
Refer to Control Authoring overview
I go by following order of consideration
Attached Properties : If functionality can be achieved, I use attached properties. Example, Numeric text box.
Control Template : When requirement can be fulfilled by customizing the control template, I use this. Example, circular progress bar.
Custom control: If control template cannot do it, I use custom control. Provided I need to customize/extend already present control. Example providing Sorting, Filtering based on header row in GridView (GridView is present in metro apps, used just to illustrate the example)
User control: Least preferred one. Only when composition is required, and I am unable to do it using custom control. Like in your example, 2 Combobox, and 1 datagrid. User controls does not provide seamless lookless feature that can be leveraged through custom control or control template.
You already have some great answers that explain the differences but also understand that custom controls and UserControls have different purposes:
A UserControl typically encapusulates some sort of composite behaviour. If you have an application that needs to edit contact details in many places, for example, you could create a custom control that has the labels and text fields for all the data laid out with a submit button that has the relevant code and reuse this control throughout your application.
A custom control is a control that is derived from one of the WPF control classes (E.G. Control, ContentControl etc.) and has to be created in code.
These control usually have a single cohesive purpose (think TextBox, ComboBox, Label) rather than acting together as a whole (although this doesn't have to be the case).
UserControl's are usually easier for people unfamiliar with WPF as they can be visually designed.
My suggestion would be to start off with a UserControl. You can always refactor this into a custom control at a later date as you become more familiar with the way WPF works. Creating your control as a custom control will require knowledge of ControlTemplates and Styles as you will need to provide your own to define a look and feel for your control.
When all is said and done, as long as the control behaves correctly, it doesn't matter which approach you use.
See this post for an example of two approaches to the same problem. The post author wanted a control which can present modal content in front of the primary content. The post author actually answered his own question by implementing it as a UserControl. I have added an answer to the post which creates the control as a custom control but both have the same end effect.
If you have a view-model and you wish to create a view for it use the User-Control.
If you need an autonomous control that has no specific view-model,
you probably need a custom-control.
If you find that the functionality you need as whole, already exist in other controls you need to override an existing control template.
(i.e: for a diamond shaped button - you need to override the button control template.)
Regarding attached-properties and attached-behaviors, those are useful when you have a control which you want to extend with more properties or you want it to behave slightly different than its default behavior.
In the provided case of the composition the OP described, it can be achieved with either user control or custom control. I would prefer a custom control since there is no specific view model provided, the "input" is only a property bound to an item collection.
Oh, and, I am sorry for slightly being late.
The best explanation is in the msdn. CustomControl is more a "virtual" name, there is no class called "CustomControl" in WPF, instead its meant creating a new class building on top of one of WPF control classes, like Control, ItemsControl and even more specific Controls like TextBox or Button.
For your specific case, a UserControl should be enough, creating a CustomControl is something that can easily be avoided. While its not a bad thing, a lot of people, especially beginners in WPF coming from WinForms tend to subclass more then necessary.
If this is somehow your first time building controls, I recommend UserControl as VS lets you design its interface more easily. Custom Controls are more powerful, but you have to CLEARLY separate your control's logic from its interface and this requires a bit more preparation.
You can easily Visually design CustomControl.
Create new UserControl (or Window). Create its xaml structure visually in Designer. Copy-paste body of the resulting xaml inside ControlTemplate of your new CustomControl (Eg. in generic theme file).
If I remember right, you are also able to visually design CustomControl template directly, in Blend.
Of course you can also instance the wip CustomControl in a Window and put the Window's Designer view as new panel above the control's xaml view in VisualStudio.
Some xaml bindings from style template don't show in Designer like this though, until I rebuild.
[ Imho GUI is mainly a visual matter and should not, and doesn't need to, be created in code. ]
Well to create a Custom control you need to implement it as a User control. Your own User control is called a Custom control. It is pretty simple.
UserControl is the base class for containing your custom content :
<UserControl>
Your custom WPF content
</UserControl>
I don't totally agree with the article. However in your case you need a UserControl that you can re-use latter in your UI.

How to implement a-form-inside-a-form with runtime embedded forms switching?

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.

WP7 - Controls - Criteria to decide which class to inherit from - UserControl or ContentControl or Control class

I am developing controls for WP7 application. I am aware that I can quickly create control by inheriting from UserControl class (that derives from Control class). Also, that such controls cannot be customized, i.e., all the properties associated with control are those harcoded in user control - they cannot overridden in xaml etc. But can somebody please share the best practises / situations as to when to inherit directly from Control class vs ContentControl/ItemControl class vs UserControl class (am I missing any other options?)?
Thanks.
Here is a brief description of each control types that you mentioned:
1.ItemsControl - it is usually used when you want to have a control with items like for example ListBox,TreeView etc. One of the most important parts when deriving from ItemsControl is to override :
GetContainerForItemOverride
IsItemItsOwnContainerOverride
PrepareContainerForItemOverride
Here is an example:
http://www.silverlightshow.net/items/How-to-inherit-from-ItemsControl-and-create-a-UniformGrid-with-containers.aspx
Note that the sample is not with the latest Silverlight version but it explains in details how to implement a custom control.
2.Control - when you want to implement a simple control that has no Content or Items properties like a TextBox for example you can derive from Control.
3.ContentControl - when you need to place some content in the control.Like for example the button Content. It depends on your need what will be the choice of the base class.
You can also take a look at the rest of the tutorials that SilverlightShow provides connected with "how to implement a custom control".
I hope that this will answer your question.

Making child control an IContainer

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.).

Categories