I am looking creating some custom controls that need to be compiled as a stand alone dll rather than with the primary application. Unfortunately so far this has meant manually creating the controls without the use of the designer since afaik you can't compile a User Control as a stand alone component. As doing things this way makes the controls rather difficult for the designers to style without putting in a lot of effort on the developers part, I am wondering if there is in fact a viable way to compile a .ascx style control into a stand alone binary?
You can turn a user control into a custom control that is in a standalone .dll, but it loses the ability of being updateable via markup.
In other words, you can build an .ascx file using markup and code, and then turn it into something similar to a control that was built exclusively with code.
Turning an .ascx User Control into a Custom Control
You have to understand that user controls are just a convenience for reusable content though - ultimately, the markup does get processed and compiled. Custom controls are really the only way to distribute a web control. IF you have to distribute controls as a library, I would concentrate on making them CSS friendly for your devs with just a few layout controlling properties, rather than messing around with .ascx.
The MSDN article http://msdn.microsoft.com/en-us/library/aa479318.aspx explains how you can do this. Basicly you precompile the application and take the resulting DLL.
Related
I am working on my final year project, in my project i am using winform c#. My project is some sort of security system including hardware.
In my project I have a lots of controls like panels, textboxes, labels etc. Till now I am using layout and it is getting slower and slower (and flickering more and more) as I am adding more controls in it.
My question is that isn't it better to generate controls when required and destroy them when I don't need them? Will it save memory?
Assuming that you use the VS Windows Forms Designer, it will create the code for you which will be loaded at runtime. There will be no difference if you load the controls in Form.InitializeComponent (as the Designer does) or in any other place where you wrote it yourself. The only thing the designer does is it creates the Form.Designer.cs file for you while you design the form, and you can use those controls the same way you would use the controls you create at runtime yourself.
Loading a lot of controls on a single form is not a good practice. And it will get slower as you add more contols. You should probably consider redesigning the GUI.
I want to use same xaml files for silverlight and wpf version of applications.
Only difference that i need is in styling. I have used styles in xaml. But for silverlight i dont want to use any styling in my xaml files, as styling is defined a application level in the form of themes.
Is there any other way to use same xaml file for silvelight and wpf versions? Otherwise I am forced to maintain separate xaml files.
you can reuse quite a bit of xaml for both, I have projects where I'm linking all the same files, xaml and code behind and it works decently.
A couple of things to be weary of is certain things don't always match up well, for example wpf has a template selector for a itemscontrol and silverlight doesn't.
Using SizeToContent tends to produce different behaviours in the two, I recommend avoiding it, I don't think it buys you anything.
I recommend having a seperate 'base' resource where you can keep your difference in the two files. things like event triggers for example aren't nearly as filled out in silverlight. you would have a base class for each version and they would abstract their differences, you could then mark the keys the same and use them as a static resource in your linked files.
Another big gotcha is you want to watch out for the order events happen for uielements, loaded,layout and apply template events get applied in different orders so if you were to make a templated control you have to be careful there, its not a deal breaker you can work around it, just be aware.
other things to be aware of
-silverlight commands take a little more effort, you have to implement ICommand, this isn't always the case in wpf, I use my implementation to help with sharing the code though.
-wpf is the superset, it has a lot of functions that silverlight doesn't have, Usually they are convienient ways of doing things, you just want to avoid those. Good Examples would be Preview events, not there for silverlight but you can usually find an event to match the behaviour.
I've a question more about 'Good Programming Practices'.
I have just started a really big project. I'm using WebGui (long story short.. it is WinForms in web) - but it's not important.
I'm creating milions of forms with milions of controls like TextBox, NumericUpDown, DateTimePicker and etc. It might happen, that I will have to change something in behavior of DateTimePicker or appearance. It will be impossible to change it in every control. I want my project to be flexible so I've got an idea..
I do separate custom controls for every type - string, numeric, date, byte.. and within I will put TextBox for example. And on every form I will put not TextBox, but MyTextBox. In fact, that MyTextBox will be just TextBox, but when I change something there, every control will be changed.
Is it good, popular pracitce in programming?
in the case of WPF this can be achieved quite easily using Styles and Templates.
in Winforms this is not possible, therefore I'd say your approach of deriving from the controls and using your own custom controls on the UI is a good practical approach which helps managing changes centrally.
If the controls were created manually in the programme, alternatively you could use a Factory clase(s) and get the Factories to create the controller object rather than just newing up.
But this might not be possible when the UI is created by dragging and dropping controls as the developer has no control over the creation of controls.
Which ever the approach you choose, the fundamental goal should be to centralize the creation logic of the controlls.
Yes, this is perfectly normal programming practice for GUI development, if the standard controls don't satisfy your requirements.
Most developers get 3rd party control suites for the extra flexibility. The benefits in buying far out weigh the benefits in building core controls yourself.
I've worked at a place that did companyTextBox, companyDatePicker and it worked ok. A couple of controls got revamped over .Net versions so these base classed controls required some surgery. Any depreciated controls were left as framework version dependent.
For special things, I do a lot of research into good custom controls on CodeProject, CodePlex, Code.Google.com,etc and implement them into the project I'm working on.
Otherwise use the stock standard controls or the suite of 3rd party controls the company I'm working for use.
My advice is to get a 3rd party suite of controls and make a ton of re-usable user controls based on the 3rd party ones. This way you can build most of the 200 forms by Drag and Dropping the user controls onto the forms. Make each User-Control Implement an Interface with Create,Retrieve,Update & Delete methods for the forms to generically work with your user controls.
First of all, I hope I'd get some advice about my practice because based on the very few books I've read, they didn't write much in the aspx page..they just built some controls and used them in the aspx page, so is this approach a good practice ?
here comes my question, I thought using web controls instead of directly writing into .aspx page is better as I could reuse the code, but now I'm creating those controls and I don't think I'll reuse them again or maybe only just one more time.
so do you think it's wise to create a control for the code instead of directly coding in the .aspx page ?
I was also working on a web user control for adding a new item to my db, and then I started planing for the update or edit control..I thought maybe I'd use the same control for both add and edit and start reusing my code, and on my way editing the control to be able to function as both add and edit control, I started with adding properties to the control, then a couple assignments in the Load method, then some checks with if...So I realized maybe a new control would be better!
I don't know, I'm thinking intuitively but I could really use a professional, experienced point of view.
Thanks for your time =)
Sometimes creating a user control, allows you to encapsulate some specific logic and ui elements into a separate class. Even if you are not reusing the control, the final code may be simpler to read and maintain. Take by example a Login control, if you take login related decisions in the user control and make those 'details' hidden in the rest of your code, then the code get simpler and easier to read and mantain!
If you're not going to reuse the code, then you don't want a user control or any other kind of control. Just put the appropriate code and controls onto the page.
If you find later that you do want to reuse it, then you can make a user control out of it.
If you know for sure that you are going to want to use a control (or some slight variation) then creating the user control is a no brainer.
For me, if it occurs to me that I may need similar functionality again in some future project then I will sometimes create a control just because I think it will be useful.
I was wondering is there any option of using Stylesheets for .NET Windows controls ?
If not, which is the best way to make the UI look consistent.I need to use VS 2005 to make
the changes in the UI.
Regards
We derive usercontrols from all controls in our system -- all the derived classes do is set the style from a central list of constants defining colours and fonts. Then we use these controls on our WinForms for a consistent look and feel.
If we want to change the style, we just change the list of constants.
This also allows is to perform UI tricks like setting the background colour of controls to a different colour when they are being edited.
If you want to make your UI consistent and pretty, why don't you give WPF a try? You will be able to organize your styles in resource dictionary, then reference to it in all the other projects.
Well guess he's talking about WinForms. Then you cant use Stylesheets. Havnt coded that much of WinForms. But guess you could have an "Settings/sheet" class that have properties of different style you are using and then set them when creating your controls.
you can use Stylesheets in web pages only not in Windows controls.
Even ASP.NET controls, which ultimately render HTML, are notoriously CSS-unfriendly. The reason is that they use tables extensively for layout, and they set a lot of inline style tags which of course do not honor the style sheet. Some work has been done to create wrappers for these controls, but it was incomplete the last I looked.
It's a shame, but our team will not use the out-of-the box controls most of the time. We've rolled our own and packaged them into an internal library. While the Microsoft controls would have been very useful, they simply don't meet our criteria for clean, accessible, styleable HTML.
Microsoft seems, finally, after something like 10 years, to have realized that this is important to a modern development team. The control output of ASP.NET MVC is far cleaner and behaves itself quite well with respect to CSS. Whether they'll eventually revisit the core ASP.NET controls is anyone's guess.