In Windows Forms applications, controls in the System.Windows.Forms library have a property named Site.
What is this property’s job in Controls?
The Site property is inherited from Component, and is very much like the Parent property of a Control.
The main difference between Parent and Site is that the value of Parent can only be a Control, while Site can have a non-visual container assigned to it.
The Component base-class is used for those non-visual tools in the Winforms designer toolbox. For example the System.Windows.Forms.Timer which can be dragged onto a Form. The PropertyGrid can be used to set its properties and assign event-handlers, all from the designer without writing a line of code.
The idea behind the System.ComponentModel classes is to provide an API for Software libraries to take advantage of design-time capabilities of an IDE such as Visual Studio. It caters to RAD (Rapid Application Development) concepts where general-purpose or generic components would take advantage of the API. For example to expose extra information about a property in the bottom section of the property-grid, or even create complete custom editors.
If you want to dive deeper into the internals you could look at Programming with Components, or if you want a quick overview, I guess Class vs. Component vs. Control may be a good starting point.
Sites bind a Component to a Container and enable communication between them, as well as provide a way for the container to manage its components.
Sites can also serve as a repository for container-specific, per-component information, such as the component name. For more information about components, see Programming with Components.
Notes to Implementers
To be a site, a class must implement the ISite interface.
Reference:
https://msdn.microsoft.com/en-us/library/system.componentmodel.isite.aspx
Related
I want to develop a custom form designer for a scripting language. The controls' properties and behavior are very very similar to the windows forms controls.
I know that design such application is not an easy task and develop it from scratch is a little to advanced for me. So I googled for it and found lots of examples in c# for custom forms designers.
I picked this one to work on top of it:
https://msdn.microsoft.com/en-us/magazine/cc163634.aspx
Most of the windows controls properties won't be used, and some will be new. Let's take a button as example, I won't need many propertie like AllowDrop, Tag, etc. Some will be new, like ControllerType and BehaviorType. Others are preety much the same but with other name, like Location which will turn to be Position.
The best approach I could think of is to create a new class derived from Button and create these new properties on this class.
I managed to implement all this but now I have a problem with the PropertyGrid. Since I'm not using most base class properties, I would like to hide them on the PropertyGrid, and if possible, rename the properties that have a diferent name. I cannot control the attributes of the base class to set [Browsable(false)].
So my questions are:
1) Is this approach I'm following correct, or is there a better one?
2) Can I control the PropertyGrid behavior like what I need or do I need to develop a custom propertygrid?
3) If I can't run away from creating a custom PropertyGrid, could someone hint me on how to do this?
I am currently working with a 3rd party ActiveX Control (an editor for topographical data distributed by Cadcorp SIS). I have to do some fairly complex stuff with it in a VB.NET (framework 4) program and am finding that the API that comes with the control is quite limited.
As of now I have made a custom control which houses the control and acts as a wrapper for it to allow me to extend the API, which works fine, but What I would really like to do it give the control more events so that I can monitor what is going on with the data more closely.
I'm not sure how to go about doing this though...
I tried inheriting from the control and I can extend it just fine, but I can't figure out how to reuse it after that. Is there some way I can inherit the control and get it to appear in the toolbox so I can just drop it onto a form? Or do I have to load it programatically? If so, how can I do it?
Any pointers, examples, tutorials or alternative ideas as to how to do this kind of thing would be welcome.
If you are not seeing your control class in toolbox it doesn’t mean that you can’t use it just modify code from your form's designer to use your inherited class
Or
You can drag-and-drop your assembly (dll) from Windows Explorer to the
toolbox in VS.NET. Or you can right click on the toolbox in VS.NET and
choose Add/Remove items. Is this what you are looking for?
Also
<ToolBoxItem(True), ToolboxBitmap("MyNamespace.MyClass.bmp")> _
Public Class MyClass
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.
These are three different things you can add to a project and I am not quite sure if I understand the difference. They all seem to for example show up in the component toolbox when working with a Form. What are some common usage scenarios for each of them? What is the difference?
The main difference between User Control, Custom Control and Component is that they inherit from different levels in the inheritance tree:
MyComponent
|-> Component
MyCustomControl
|-> Control
|-> Component
MyUserControl
|-> ContainerControl
|-> ScrollableControl
|-> Control
|-> Component
So, in short you get a different amount of pre-wired functionality with the different options.
When would you use the different options? (these are thoughts and opinions, not truths)
Create a component if you want to provide functionality without UI (such as Timer components, data sources, ...)
Create a custom control if you want to make a component where you have full control over its visual appearance, and you don't want any baggage of unnecessary functionality. Typical cases would be simple controls with limited functionality (such as a button)
Create a user control if you are going to combine existing controls into reusable building blocks (such as two lists with buttons where you can move items between the lists).
Adding to what Fredrik said, generally components and custom controls would be used when you plan on reusing them across projects. Use user controls when you would only be using it in one project.
I believe the last statement is not correct in my opinion .
I create user controls for many different reasons.
The main reason is so that if per say I design an interface of multiple controls
grouped together.
I first create a class library , then I add user controls to it .
Now if i need to change any part of the logic behind how the user control works I can very easily. Also this class library can be used multiple times.
Also within the same classy library I can have multiple classes that can be shared and used for any of my user controls.
This is the main reason I use user controls.
And if you make a change to your user control or class library .
once you build the job .
the dll will dynamically up date in the bin folder .
So if i am referencing this in another project
Those changes will also appear in new project .
Also it doesn't use the same paint routines as the form and anything you have loaded on the form.
So user controls gives us the ability to be very modular
And i Can have multiple user controls that share the basics classes of the class library ...
So a user control purpose is just not for one project . It has no limitations in that respect.
jeff
The main difference between them-
User Control is a page file with extension .ascx which can only be
used within a single application or project But custom controls are assemblies(dll files) that can be used in multiple applications.
Using .NET 2.0 with WinForms, I'd like to create a custom, multi-columned menu (similiar to the word 2007 look&feel, but without the ribbon).
My approach was creating a control, and using a left/right docked toolstrip, I have constructed a similar look&feel of a menu. However, there are a few shortcomings of this solution, such as
the control can only be placed, and displayed within the form;
if the form is too small, some area of the control won't be displayed;
the control also have to be manually shown/hidden.
Thus, I'm looking for a way to display this control outside of the boundaries of the application. Creating a new form would result in title-bar deactivating on display, so that's also out. Alternatively, any other approach to create a customized menu would be very welcomed.
Edit: I don't want to use any commercial products for this; and since it's about a simple menu customization, it's not related to Microsoft's ribbon "research" in any way.
unless you are in the business of providing .net components, you should be looking to buy it off the shelf. Its a lot of work getting such a control right - There are already vendors providing this kind of UI. e.g. ComponentOne
if you are trying to build this component as a product, you should look at the link below. Apparently Microsoft has a 'royalty-free' license around the Office UI to protect their R&D investments. As of now you need to tell them that you are using something similar to the Office UI. More of that here
The MenuStrip class has a Renderer property. You can assign your own ToolStripRenderer derived class to customize the painting. It's a fair amount of work.