Summary
Hi All,
OK, further into my adventures with custom controls...
In summary, here is that I have learned of three main "classes" of custom controls. Please feel free to correct me if any of this is wrong!
UserControls - Which inherit from UserControl and are contained within an ASCX file. These are pretty limited in what they can do, but are a quick and light way to get some UI commonality with designer support.
Custom Composite Controls - These are controls that inherit from WebControl where you add pre-existing controls to the control within the CreateChildControls method. This provides great flexibility, but lack of designer support without additional coding. They are highly portable though since they can be compiled into a DLL.
Custom Rendered Controls - Similar to Custom Composite Controls, these are added to a Web Control Library project. The rendering of the control is completely controlled by the programmer by overriding the Render method.
My Thoughts..
OK, so while playing with custom composites, I found the following:
You have little/no control over the HTML output making it difficult to "debug".
The CreateChildControls (and subsequent methods) can get real busy with Controls.Add(myControl) everywhere.
I found rendering tables (be it for layout or content) to be considerably awkward.
The Question(s)..
So, I admit, I am new to this so I could be way off-base with some of my points noted above..
Do you use Composites?
Do you have any neat tricks to control the HTML output?
Do you just say "to hell with it" and go ahead and create a custom rendered control?
Its something I am keen to get really firm in my mind since I know how much good control development can cut overall development time.
I look forward to your answers ^_^
I say go ahead with the custom rendered control. I find that in most cases the composite can be easier done and used in a UserControl, but anything beyond that and you'd need to have a finer degree of control (pun unintended) to merit your own rendering strategy.
There maybe controls that are simple enough to merit a composite (e.g., a textbox combined with a javascript/dhtml based datepicker, for example) but beyond that one example, it looks like custom rendered controls are the way to go.
Here's another extension method that I use for custom rendering:
public static void WriteControls
(this HtmlTextWriter o, string format, params object[] args)
{
const string delimiter = "<2E01A260-BD39-47d0-8C5E-0DF814FDF9DC>";
var controls = new Dictionary<string,Control>();
for(int i =0; i < args.Length; ++i)
{
var c = args[i] as Control;
if (c==null) continue;
var guid = Guid.NewGuid().ToString();
controls[guid] = c;
args[i] = delimiter+guid+delimiter;
}
var _strings = string.Format(format, args)
.Split(new string[]{delimiter},
StringSplitOptions.None);
foreach(var s in _strings)
{
if (controls.ContainsKey(s))
controls[s].RenderControl(o);
else
o.Write(s);
}
}
Then, to render a custom composite in the RenderContents() method I write this:
protected override void RenderContents(HtmlTextWriter o)
{
o.WriteControls
(#"<table>
<tr>
<td>{0}</td>
<td>{1}</td>
</tr>
</table>"
,Text
,control1);
}
Rob, you are right. The approach I mentioned is kind of a hybrid. The advantage of having ascx files around is that on every project I've seen, designers would feel most comfortable with editing actual markup and with the ascx you and a designer can work separately. If you don't plan on actual CSS/markup/design changes on the controls themselves later, you can go with a custom rendered control. As I said, my approach is only relevant for more complicated scenarios (and these are probably where you need a designer :))
I often use composite controls. Instead of overriding Render or RenderContents, just assign each Control a CssClass and use stylesheets. For multiple Controls.Add, I use an extension method:
//Controls.Add(c1, c2, c3)
static void Add(this ControlCollection coll, params Control[] controls)
{ foreach(Control control in controls) coll.Add(control);
}
For quick and dirty rendering, I use something like this:
writer.Render(#"<table>
<tr><td>{0}</td></tr>
<tr>
<td>", Text);
control1.RenderControl(writer);
writer.Render("</td></tr></table>");
For initializing control properties, I use property initializer syntax:
childControl = new Control { ID="Foo"
, CssClass="class1"
, CausesValidation=true;
};
Using custom composite controls has a point in a situation where you have a large web application and want to reuse large chunks in many places. Then you would only add child controls of the ones you are developing instead of repeating yourself.
On a large project I've worked recently what we did is the following:
Every composite control has a container. Used as a wrapped for everything inside the control.
Every composite control has a template. An ascx file (without the <%Control%> directive) which only contains the markup for the template.
The container (being a control in itself) is initialized from the template.
The container exposes properties for all other controls in the template.
You only use this.Controls.Add([the_container]) in your composite control.
In fact you need a base class that would take care of initializing a container with the specified template and also throw exceptions when a control is not found in the template. Of course this is likely to be an overkill in a small application. If you don't have reused code and markup and only want to write simple controls, you're better off using User Controls.
You might be able to make use of this technique to make design-time easier:
http://aspadvice.com/blogs/ssmith/archive/2007/10/19/Render-User-Control-as-String-Template.aspx
Basically you create an instance of a user control at runtime using the LoadControl method, then hand it a statebag of some kind, then attach it to the control tree. So your composite control would actually function like more of a controller, and the .ascx file would be like a view.
This would save you the trouble of having to instantiate the entire control tree and style the control in C#!
Related
I have 2 questions regarding a tutorial that I am going through.
Q1.
Through the tutorial they use a datasource
Using the data in the app
To use the data in the app, you create an instance of the data source
as a resource in App.xaml. You name the instance feedDataSource.
BR211380.wedge(en-us,WIN.10).gifTo add a resource to an app
Double-click App.xaml in Solution Explorer. The file opens in the XAML editor.
Add the resource declaration, <local:FeedDataSource x:Key="feedDataSource"/>, to the root ResourceDictionary, after the
MergedDictionaries collection.
and then they use it in the OnLaunch method.
var connectionProfile = Windows.Networking.Connectivity.NetworkInformation.GetInternetConnectionProfile();
if (connectionProfile != null)
{
FeedDataSource feedDataSource = (FeedDataSource)App.Current.Resources["feedDataSource"];
if (feedDataSource != null)
{
if (feedDataSource.Feeds.Count == 0)
{
await feedDataSource.GetFeedsAsync();
}
}
}
I am wondering why do they store it in resource? Wy not just create an instance of the class and get the results from it?
Q2.
Later down the article they use this datasource items with "grid view items". I seen this done in their other template projects. I am wondering is there the standard way of making your interface?
At first I thought maybe just drop some image buttons on the screen and hook up their click events but now I am not sure.
The XAML Resource essentially does create an instance for you and makes it available in the Resources collection, so you could instantiate the class yourself. Having it as a resource keeps this object around and makes it accessible across the various pages in your application. You could certainly create the class explicitly, and if you enforce the singleton pattern on it, it would be semantically equivalent.
I'm not sure I see the context of your second question in the tutorial, but in general the pattern you are seeing is Model-View-ViewModel (MVVM), which is the de facto standard pattern for Windows Store apps. feedDataSource is providing the model and portions of that are assigned to DefaultViewModel, which is the DataContext for all of the binding markup in the XAML pages, which are the views. The idea behind this to separate your data from your model, so that when you do things like load a new data feed, etc., all you need to do is change the data source, and all of the data binding markup will automatically reflect the new data in your user interface.
If you find yourself writing code that looks like TextBox.Text = "My text", then you're deviating from the pattern.
I have a WinForms app that I am currently implementing a translation engine in. What I have so far is a bunch of text documents that follow the syntax like:
messages.manualupdate="There is a manual update available for ProgName.\n\nDo you want to update to version {0}.{1}.{2}{3}?"
messages.errorcopy="Clicking OK will copy the error so you can paste it elsewhere!"
messages.error="Error"
messages.notsupported.title="Unsupported client"
messages.notsupported.message="This version is no long supported. Please wait for an update."
I have lots of these for different languages, for example:
messages.manualupdate="é disponibile un'aggiornamento manuale del programma ProgName.\n\nVuoi aggiornare alla versione {0}.{1}.{2}{3}?"
messages.errorcopy="Cliccando OK eseguirete una copia degli errori visualizzati"
messages.error="Error"
messages.notsupported.title="Client non supportato"
messages.notsupported.message="Questa versione non è utilizzabile al momento. attendi il prossimo aggiornamento!"
I then parse this into a DynamicObject which I can access like language.messages.notsupported.error. What I would like to know is if I can somehow link all the controls on the form to use variables from the dynamic object on creation. For instance I have a button on my form that I want to have the text "Error" in. Before the form shows, I set the language variable to the users chosen language, and then when the form shows it simply loads the text from language. Is there a way to do this in the designer rather than having to write a method that is called in the Forms constructor as it seems to me like a little bit of a waste to set all the button text to a value and then change them all when the form loads. I'm looking for a sort of binding, but to the controls Text parameter.
Anyone have any ideas?
MSDN has a walkthrough on string localization that might be of use to you link
Honestly, the approach you are trying to avoid looks best to me. I will suggest you to create a property for the control where you are trying to set the Text. In Set attribute, check for the language selected and get the appropriate text for you.
public string Error
{
set { _errorLabel.Text = value; }
}
private void SetText()
{
if(EnglishSelected)
Error = "English";
}
Regarding waste of time, well, I will just suggest not to set anything in designer and directly set the property in Load form. But I would like to add one more point here that any of the approach will not hit your application speed. First its about making your application expandable and maintainable and then about making it fast. Setting logical things in designer is always a bad practice. If your application is not tiny/small then I will suggest you to follow some design patterns like MVP and move all this logical things in Presenter. Not trying to preach but just suggesting.
And yes, in our company one of team is working in localization part of the application. Using resource may be a better way of doing this.
Hope it helps.
I have created a web page that I use as a small dashboard to hold issue or no issue. It works great. The page uses an .aspx and .aspx.cs. I would like to be able to reuse the information on this page on other pages. My site already uses master pages and I have not been able to find an easy way to include this information.
How can I use an include from a page that has coding in the code behind easily?
Typically you use Web User Controls for this.
Web User Controls allow you to package up other controls into one that you can drop onto multiple pages. They are great for common UI items such as address entries, dashboards, etc. Basically anything that needs to be the same across multiple pages.
At the risk of seeming very obvious - do you mean usercontrols. These will allow you to reuse chunks of functionality across your site.
I guess this question falls into two categories: User Controls, and Code Reuse. Not sure which one you are after.
User Controls
If you are talking about the controls on your page you will want to create a common user control.
Code Reuse
You need to create a common class (whether it is static or not depends on how you intend to use it) and define functions within that class.
For instance, lets say you have a page that you want to print "Hello World!" on any aspx/.cs page.
You could do this
public static class MyClass
{
public string PrintHelloWorld()
{
return "Hello World!";
}
}
Then you call it from any of your pages like so:
MyClass.PrintHelloWorld();
Right click on the project > Add New Item...
Select User Control (.ascx)
Put your markup & code behind there.
Then you add that control in any other page (includding other controls [although I wouldn't recommend that])
It sounds like you may want to create an ascx User Control.
http://msdn.microsoft.com/en-us/library/ie/2x6sx01c.aspx
I'm building form validation controls for our C# ASP application. The bulk of the work is handled by a BaseValidator control (subclassing System.Web.UI.UserControl), which also has the markup for the validation output. This is then extended by subcontrols like PasswordValidator, that provides the Validate method and any extra fields needed by that validator control.
(The end goal is to have controls like <uc1:PasswordValidator ControlId="txtPassword" /> which we can plop into any form with minimum duplication.)
However, PasswordValidator.ascx.cs cannot access the form elements defined in BaseValidator.ascx; the only way I've found to do so is to duplicate the markup in each subcontrol's *.ascx file. How can I extend BaseValidator.ascx.cs and access BaseValidator.ascx's markup in the subclass?
I'm pretty sure you'll have to create Server Controls to accomplish this. Meaning, you'll need to generate the outputted Markup from code in the control rather than in the .ascx file.
If you have a true baseclass for your BaseValidator control which your PasswordValidator extends, then any markup/controls in the baseclass should be available through protected properties. I would even go so far as to argue that a true base should not have an ascx portion. The base class should provide methods and properties that expose controls to built on the fly (probably during Page_Init to maintain viewstate).
If you have 2 separate controls on the same page, your parent page can be modified to provide brokerage methods to allow such communication.
If you have the PasswordValidator and you just need the controls/markup, you can use the LoadControl method to create an instance of the BaseControl in memory, access its controls/markup programmatically and either add it or destroy it depending on what you want to do with it.
Barring any of that, it would be just as #Shawn said. Server controls.
Thanks for the suggestions.
I solved this using a service and the strategy pattern. There is a central FieldValidator class which provides validation for any user interface. For the web interface, these methods are exposed through a WebService and (through the WebService) a UserControl. There are no issues with accessing the page elements, because there is now only one UserControl class that stands between the form and the WebService.
For example, <uc1:FieldValidator ControlType="Password" ControlToValidate="txtPassword" runat="server" > will plop down fully-functional clientside and serverside validation, with no need for code behind. Great! :)
(I mentioned resolution a while back in a reply to my question, but I can't mark that as answered.)
I'm creating a SharePoint web part in C# that is using an UpdatePanel for some AJAX magic. Everything is working fine, but I'd like to know how to lay out my controls visually (without using SharePoint Designer). I just have two dropdownlists, some labels, a button, and a textbox. I am creating them within the overridden CreateChildControls. Thanks!
add a container panel around your controls and give it a class. Add the panel to the UpdatePanel's container. Add all other controls to the new Panel's Controls.
You can now use css to do your styling, using the container panel's CssClass as reference.
in code:
protected override CreateChildControls()
{
// .. creation of updatepanel, say upd1
Panel container = new Panel{CssClass = "webpartContainer"};
upd1.ContentTemplateContainer.Controls.Add(container);
container.Controls.Add(dropdown1); // etc. etc.
}
The Css:
.webpartContainer
{
/* if needed add some style here also */
}
.webpartContainer select
{
/* add style */
}
.webpartContainer .specificClass
{
/* give controls a class of their own in CreateChildControls
if controls of the same type need different styling
(i.e. you have more than 1 select that need to look different) */
}
there are a couple of ways you can lay them out. you can add a Table object and add rows, cells, etc. and add your controls to the cells.
Alternately, you can override the RenderContents method and output HTML directly to the write that is passed in as a parameter. If you do this method (its probably less work and more efficient then using the Table objects), you should use a StringBuilder to build your HTML then output the results to the writer. This method should gain you some performance.
Sadly, there is no visual WYSIWIG editor for this method.
Unfortunately, there is no visual designer for web parts that are created programmatically.
You can use a user control and the SmartPart web part from codeplex to gain advantage of the visual designer for .ascx user controls.
You can use ASCX files in web parts.. just load it from your webpart class in CreateChildControls like so:
var control = Page.LoadControl("/_CONTROLTEMPLATES/yourproject/your.ascx");
Controls.Add(control);
This way you can use the normal way with Visual Studio to layout your webpart. Much nicer than building HTML in code which is a pain to say the least.
(this is also much better than using SmartPart which causes issues with the trustlevel and deployment)