Is there any way to create UI components like Telerik,DevExpress for Windows Forms. Are there any specific namespaces for this in the .NET framework . If there any please add them in here.
The closest Winforms comes to theming is child controls inheriting their parents' UI properties by default. That's pretty blunt though. 3rd party control sets do allow theming but you're not going to see anything like it in the stock .NET BCL.
But, with some clever subclassing you could create your own set of "themed" controls. Assuming you don't want to spend $ on a 3rd party package. You could pick a set of standard Winforms controls, inherit each one with your own class e.g. KalgTextBox, KalgForm etc.
Then have each class implement an interface like IKalgThemedUi with a single method like SetTheme that takes a KalgTheme object and passes it on to its children, if any, or a single property like KalgTheme which on the getter would do exactly what the method would do. The KalgTheme object would of course contain all the theming information for your control set. The theming could be as simple or complex as you want.
A couple of theme/skinning code examples:
A nice but advanced framework
A simple but not so great framework
A CSS-like implementation
Related
In Xamarin Forms what is the difference between the EventHandlerBehavior and EventToCommandBehavior? I have been using the former successfully, but the latter was suggested to me to use instead. EventToCommandBehavior is less verbose which is a good thing.
About difference between EventHandlerBehavior and EventToCommandBehavior, I have some point, you can take a look:
For EventHandlerBehavior, you need to install Behaviors.Forms in your project firstly, behaviors let you add functionality to controls without having to subclass them. Instead, the functionality is implemented in a behavior class and attached to the control as if it was part of the control itself. Behaviors enable you to implement code that you would normally have to write as code-behind, because it directly interacts with the API of the control in such a way that it can be concisely attached to the control and packaged for reuse across more than one app.
For EventToCommandBehavior,the EventToCommandBehavior is a custom class, there are need you create EventToCommandBehavior class derives from the BehaviorBase class firstly, then implementing Bindable Properties, for detailed info, you can take a look:
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/behaviors/reusable/event-to-command-behavior
So I suggest you can use EventHandlerBehavior, because you don't need to create many code behind.
2021 Edit
EventHandlerBehavior from community-toolkit is now equivalent to EventHandlerBehavior.
Documentation:
https://learn.microsoft.com/en-us/xamarin/community-toolkit/behaviors/eventtocommandbehavior
In Xamarin Forms what is the difference between the EventHandlerBehavior and EventToCommandBehavior?
Eventhandler like:
OnTextChanged, OnSelectedIndexChanged etc are defined behind the C# code file of XAML. These methods are completely tied to your controls you define behind your pages/controls.
However the Behaviors in Xamarin allows us to ATTACH them to any View. Your behavior will know which controls it is being attached to. Hence, for those Events like OnTextChanged/OnSelectedIndexChanged can be controlled from the Behaviors.
EventToCommandBehaivor: As we already know that Behavior get attached to any view; you have to define the behavior as such that It will expose the BINDABLE property for Commands. EventToCommandBehavior is just a normal behavior control which supports binding the Command and the Eventname. Which in runtime, whenever the Event for the control get fired, your behavior will execute the Command attached making it more ViewModel friendly.
Remember if you use Events; you are writing them behind the code base than ViewModel your logics are in two separate places. If you want to properly separate the logics from View and Model then then you have to use EventToCommandBehavior.
Let me know if you need more info.
I have a C++/winrt project with a complex and dynamic xaml interface created in C++ code. Now I am moving to the latest VS 15.9.0 Preview 3, which has platform support for C++/Winrt and also allows use of the xaml designer in such a project. But I don't want to use the designer and have turned it off in Tools/Options/Xaml. The result is that none of my programmatic xaml elements appears. The project seems to expect me to enter these elements in a xaml code page, rather than using C++, e.g. Grid(), StackPanel(), view.RowDefinitions.Append(), view.SetRow() etc. The GeneratedFiles folder is now full of items that were not present in the previous project, yet can't be removed. Is it still possible to use the C++ interface for xaml, and what must be done to enable it if so? Thanks.
Ryan is correct: C++/winrt does support programmatic creation of xaml, and it works great. With the help of a couple of c++/winrt guys at MS I think I also know why my code was not doing anything. In the former version of my app I had declared MainPage as a C++ class, not a struct, and had assigned the starting Grid for the xaml by getting the current Window and setting currentWindow.Content(theGrid). But in the new template app MainPage is a struct, which might matter, and while setting window.Content that way no longer works, this does: this->Content(theGrid). Leaving aside some irrelevant issues about declarations in the BlankApp, this I think is the answer. Programmatic xaml works if you set that initial content as above.
Unfortunately, this is not the intended way to use this UI system. XAML-based UI systems are descendants of WPF, which relies on the Model-View-ViewModel (MVVM) pattern.
This pattern intends three types of classes to make up your application: Views, which are primarily written in XAML, and only deal with displaying data they are given; ViewModels, which are the wrapper and translator to give the views data, and to give the models commands; and lastly, Models, which are your backend business-logic classes.
Your instinct to not trust the designer is reasonable - it generates messy and unidiomatic XAML code. But it is an excellent way to preview the way your XAML code looks.
To get back to your specific situation, there are real problems in the library's API that will be serious roadblocks to programmatically define a UI in C++. Instead, you will want to use XAML to declare the UI. Adding and removing grid column definitions is not something that is well-supported, but using StackPanels and DockPanels is the normal way to do this.
If you have more specific questions, feel free to open a new question here, but do bear in mind that you may want to search first under the tags mvvm and wpf in addition to xaml, c++-winrt, and winrt.
If you have more questions that are rather broad and may be too broad for the main site here, feel free to join the WPF channel on chat, but bear in mind that most of us don't have experience in WinRT specifically.
Im my application I want to implement the feature of when a user click on a button show a Panel which will consist of some user controls. I know In Java I can easily use Jpanel and use setVisible() method to get this done easily. But this is an MFC application. I couldn't find any built or customized component that I can use for my purpose.
I also tried GroupBox. But it is not grouping the components logically.
What would be the best approach for this?
As user1793036 says, start by creating a dialog resource and CDialog derived class for the panel. In the dialog resource properties turn off the Title Bar style. In the code call Create for the dialog and then SetWindowPos to place it where you want it to appear.
MFC is nothing but a thin wrapper over Win32 API for windows and controls. The core Win32 API doesn't provide any feature to group controls in a group-box or panel. One way is to have a window and make that window parent of all required controls. Unfortunately, this isn't easy to do.
I suggest you, since you are learning, to drop the idea. Instead, learn what you can achieve with existing set of features provided by MFC/Win32. With MFC/Win32, you would, mostly need to derive/subclass a class/window to get something fancy (such as colored list-control).
I was looking at the Firefox Add-ons Manager UI (pictured below) and really liked the expandable list used to show settings or properties for each add-on.
Firefox Add-ons Manager http://uploads.tech-buzz.net/Firefox3Beta3ComingonMonday_859/get_addons.png
I liked it enough to want to include something similar in one of my applications. The problem is, I don't know, exactly what the control is called (it doesn't seem to be "expandable list"), nor do I know if there is an implementation available for use in my own application (so I wouldn't have to reinvent the wheel.)
This isn't the first time that I've seen some cool piece of UI and wanted to incorporate it into something I'm working on, but have had no idea if I would have to design it from scratch. So I generally end up reworking my UI to use standard UI widgets to save time.
This got me thinking, is there some place that has a catalog of a bunch of UI widgets with names and what platforms/languages they are implemented for/in?
UPDATE
Turns out this control is called a Rich List Box, and it seems to only be implemented in XUL.
To answer your question, no, there isn't a universal catalog anywhere, though MSDN is as good a place as any to find definitions of most common UI elements.
The specific widget you ask about is generally called an accordian (wikipedia)
Can You tell me about subj?
For example I need to create new custom control that must be derived from datagrid and toolbar. And I want that new control to expose/propagate properties of base controls in order they to be accessed easily. The only way I know is deriving a class. Then descendant automatically gets all properties of ancestor. But multiple deriving in C# is prohibited, so I don't know how to expose properties and other behavior of second control... Styling and templating of such custom control is also needed.
Thanks!
In WPF inheritance is "out". ;O) Actually, it was complicated before WPF already, but with WPF you get various really powerful alternatives.
For the basic control I thing you'd better go with composition, create some usercontrol and make it contain a ToolBar and a DataGrid. You can then expose these as public properties, if you need to manipulate them from outside.
For special feature additions, attached properties are a very versatile mechanism.
Watching a window from windowsclient.net is a good place to start.
Make sure you understand dependency properties well.
Reading wpf blogs is my best guest for what to do then.