i am using DevExpress and i'm creating and extended TextEdit.
When i extend from a normal TextBox it's all ok. Behind the code i use simply:
public partial class AutocompleteTextBox : TextBox
And in XAML i start with:
<TextBox x:Class="...">
And all is fine. Now i want change the base class from TextBox to the DevExpress's EditText control. So i changed the class in code to inherit from the TextEdit istead of TextBox but in XAML it give me the error that partial class must have the same base class. The problem is that i don't know what to do. If i use:
<DevExpress.Xtra.Editors.TextEdit x:Class="...">
it give me error.
What i need to do?
Related
I have an issue, and I don't know if I can do that, or if there is another way to do that. I have an abstract class called "BasePage", it is my .NET Standard library, so I can't access to System.Windows namespace. Its declaration is:
public abstract class BasePage<VR> where VR : new()
EDIT: The class above has a public property to access to VR
So now, for each platform (WPF, Xamarin, etc) I have to create its own implementation of the class begin VR the content control of each platform (UserControl for WPF, for example). I already did it and this is:
public class WindowsBasePage : BasePage<UserControl>
Now, every time I want to create a page to add content to a window, I have to create something like this:
public partial class UserPassPage : WindowsBasePage
{
public UserPassPage()
{
InitializeComponent();
}
}
The problem becomes when I have to set it in the XAML file (the View). I can create it and it builds:
<local:WindowsBasePage x:Class="Bitture.AppManager.Manager.UserPassPage"
[...]
xmlns:local="clr-namespace:Bitture.AppManager.Manager"
mc:Ignorable="d" >
</local:WindowsBasePage>
but I can't add components (like buttons, text, grids, stackpanels, etc). I want to know If I can do it with my current code or there is something I have to change. Because I have to access to the generic type WindowsBasePage that inherits from
class WindowsBasePage : BasePage<UserControl>
I am not sure what you are trying to do here but you can't add UIElements to a custom class of yours that doesn't inherit from any of the common WPF base classes such as for example Panel or ContentControl, and expect it to be rendered as a UserControl or some other WPF control.
This won't work. WPF knows about how to render WPF controls but it doesn't know how to render a custom BasePage<UserControl>.
I'm writing a wpf program that needs several usercontrols that look exactly the same but perform different functions. With winForms, I could just extend the base control and add the functionality, but as far as I know, it's impossible to inherit xaml files. Is there any way I can have different codebehind classes that all use the same xaml file for their control?
You might be able to do this using MVVM pattern and create multiple VMs which perhaps implement the same interface. The XAML view could then be bound to any of your VMs relying on the fact they share the same interface.
In this approach you'd not use the code behind at all.
One way to do it is by using inheritance. A very simple example would be a UserControl with a single button, that should display different contents in a MessageBox.
We will have something like this:
public abstract class SomeUserControl : UserControl
{
//declared by XAML (can be made public with x:FieldModifier="public")
public Button MyButton;
//code-behind
public SomeUserControl() {
InitializeComponent();
}
}
public class MySpecialControl : SomeUserControl {
public MySpecialControl() {
MyButton.Click += (sender, e) => MessageBox.Show("Bla");
}
}
To use the MySpecialControl, just declare it in XAML like you did with your previous one:
<myNamespace:MySpecialControl />
Note that you can also create an abstract method for the button click, if the variation in behavior is not so big.
With winForms, I could just extend the base control
And one can't do similar in WPF?
Create a custom composite control with a dependency property(ies) which would set the mode of the control to fit its the target consumer's needs.
The control could be based on an existing control or controls.
With WinForms programs I've become accustomed to marking the Modifiers property of a control as 'Private' to prevent external classes and whatever else have you from being able to see and mess with them.
Being still very green with WPF, I see no obvious equivalent in WPF that allows me to make it so external classes cannot see a control I drop onto a form or another user control or what not. I did notice something of x:FieldModifier = "Private" but I get the error "x:FieldModifier = "Private" is not valid for the language C#".
How do I mark a control as Private so it cannot be viewed or accessed by external class objects?
TL;DR
Most of the time you don't need to worry about this in WPF. However:
If you name a XAML element using the x:Name attribute, then you can use the x:FieldModifier attribute to control the visibility of the auto-generated field representing that element. This attribute value is language- and case-specific.
If you don't name a XAML element, then don't bother using the x:FieldModifier attribute.
Read on for a more detailed explanation.
Explicit naming and generated fields
If you create a new WPF application project in Visual Studio, it will create a MainWindow class, the XAML for which looks something like this:
<Window x:Class="StackOverflow.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
</Grid>
</Window>
If you look at the code-behind class for this window, it will look like this:
// Several using statements...
namespace StackOverflow
{
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
}
}
Note the use of the partial keyword to denote this as a partial class. If you navigate to the project's obj\Debug folder using Windows Explorer, you will find a file called MainWindow.g.cs: it is this file that contains the code generated by the IDE from your XAML (it is basically the equivalent of the *.Designer.cs file from WinForms).
Your window has a Grid on it, but note that it is not surfaced directly anywhere in the code for MainWindow. Now edit your XAML to give the Grid a name:
<Grid x:Name="_myGrid">
Compile the application, and open the MainWindow.g.cs file again. You will see that the following line has been added:
internal System.Windows.Controls.Grid _myGrid;
Setting the x:Name property of the element in the XAML has caused the code generator to add a field with that name. The field is marked as internal which means it is accessible to all types in your project, but not to any other projects that reference your project.
So basically, if you do not explicitly name an element in the XAML using the x:Name attribute, the code generator will not create a named field for the element in the code-behind class, and your element will effectively be private (this means that the class itself cannot access the element directly either).
Nameless UI elements can still be accessed from code (if you have an instance)
An element without a name can still be accessed via code, by "walking" the visual tree of a Window instance. For example, because the window's content is set to a single Grid element, you can access that grid through code like so:
Grid grid = (Grid) this.Content;
this here refers to the MainWindow class instance.
WinForms has exactly the same "problem" as WPF in this regard: even controls that are not explicitly named can still be accessed through code. Imagine a WinForms Form with a single Button control on it. You can access that button like so:
Button button = (Button) this.Controls[0];
The fact that the button had a default Modifiers value of "Private" did not stop the code from being able to access it.
The FieldModifier attribute controls generated field visibility
Coming back to WPF, particularly if you're using the Model-View-ViewModel (MVVM) pattern, you will rarely need to explicitly name your elements in the XAML, hence the default behaviour will be fine. However, if you do find that you need to name your XAML elements, and you wish to "hide" these elements, then you can use the x:FieldModifier attribute to set the visibility of an element to private instead of the default internal. The value used for the attribute is language-dependent and case-sensitive, eg. for C#:
<Grid x:Name="_myGrid" x:FieldModifier="private">
I'll try to explain what I'm after. I don't know the technical term for it, so here goes:
Example 1:
If I place a ListView on a Form and add some columns I am able, in Design-Time, to click-and-drag the columns to resize them.
Example 2:
Now, I place a ListView in a UserControl and name it "MyCustomListView" (and perhaps add some method to enhance it somehow).
If I now place the "MyCustomListView" on a Form I am unable to click-and-drag the column headers to resize them in Design-Time.
Is there any way to easily make that happen? Some form of "pass the click-and-drag event to the underlying control and let that control do its magic". Im not really looking to recode, just pass on the mouseclick (or whatever it is) and let the, in this case, ListView react as it did in the first example above.
The Windows Forms designer has dedicated designer classes for most controls. The designer for a ListView is System.Windows.Forms.Design.ListViewDesigner, an internal class in the System.Design.dll assembly. This class gives you the ability to drag the column headers.
A UserControl uses the System.Windows.Forms.Design.ControlDesigner designer class. It doesn't do anything special, just puts a rectangle around the control with drag handles. You can see where this is heading: after you put your user control on a form, it is ControlDesigner that is used to design the class, ListViewDesigner is not in the picture. You thus lose the ability to drag the column headers. Also note that ControlDesigner doesn't give access to the controls inside the UC.
That's fixable however by creating your own designer. Start with Projects + Add Reference, select System.Design. You'll need to add a public property to the UC to expose the list view and apply the [DesignerSerializationVisibility] attribute to allow changed properties to be saved. And apply the [Designer] attribute to the UC class to replace the default designer. It all should resemble this (using the default names and a ListView that displays "employees"):
using System;
using System.ComponentModel;
using System.Drawing;
using System.Windows.Forms;
using System.Windows.Forms.Design; // Note: add reference required: System.Design.dll
namespace WindowsFormsApplication1 {
[Designer(typeof(MyDesigner))] // Note: custom designer
public partial class UserControl1 : UserControl {
public UserControl1() {
InitializeComponent();
}
// Note: property added
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
public ListView Employees { get { return listView1; } }
}
// Note: custom designer class added
class MyDesigner : ControlDesigner {
public override void Initialize(IComponent comp) {
base.Initialize(comp);
var uc = (UserControl1)comp;
EnableDesignMode(uc.Employees, "Employees");
}
}
}
The list view in the user control can now be clicked and designed as normal.
is there a way to have a WPF UserControl Class to be a class with a Template type?
e.g.
public partial class MyControl : UserControl
should be:
public partial class MyControl<MyData> : UserControl
as I always get compile errors that MyControl than has no reference to InitializeComponents which is in the automatic generated part of the class.
The problem is, that I can't tell in the xaml part of the class that the usercontrol is of type MyControl<MyData>. I even tried MyControl<MyData> ...
No, you can't declare a generic type in XAML. From http://social.msdn.microsoft.com/forums/en-US/wpf/thread/02ca0499-80af-4c56-bb80-f1185a619a9e:
Hello, you can use generic as long as
you don’t use XAML. But unfortunately,
if you want to use XAML to define your
control, you can’t use generic…
You can create a control in XAML that inherits from a generic type by putting a x:TypeArguments attribute on the root tag, but the control itself must be concrete.