My view's XAML is only containing a custom control.
A bit further, in a Resource Dictionary, I have a Style for this custom control, and inside this, I have a TextBox. My goal would be to reach this TextBox from the view's code behind, and set it's focus, when the view's DataContext changed.
I tried to use x:Name to give a name to the custom control on the view's XAML, and also give a name to the TextBox inside the control's style (so essentially trying to reach it from code behind like: this.MyCustomControl.SearchTextBox). This did not work.
What would be the best practice to solve this issue?
This is what I would do.
Create a TemplatePart attribute on top of your custom control for the TextBox.
[TemplatePart(Name = "YourTextBoxName", Type = typeof(TextBox))]
Then inside the OnApplyTemplate override method, get a reference of the TextBox.
// You might want to add property error handling here
// so if the TextBox is not found, throw an exception.
// Doing so forces other people will have to implement
// the SAME PART in their own stylings.
_textBox = (TextBox)GetTemplateChild("YourTextBoxName");
Then all you need is to create a public method SetFocus that your code behind class can have access to.
public void SetFocus() => _textBox.Focus(FocusState.Programmatic);
Try visual tree helper
VisualTreeHelper.GetChild(object, index)
msdn link
Related
I have made a toolbar that has a Search Textbox, using the visual studio built in search for the toolwindowpane: https://learn.microsoft.com/pt-pt/previous-versions/visualstudio/visual-studio-2015/extensibility/adding-search-to-a-tool-window?view=vs-2015&redirectedfrom=MSDN
That is working just fine right now after overriding the methods, however i also added a toolbar to the toolwindow from the vsct file, however it is positioning the search and the toolbar in the same row:
Is there any way to position the search bar underneath the toolbar just like the solution explorer in visual studio? If not, is there a way to decrease the toolbar size so it uses the minimum space so it doesn't look weird like in the picture?
Thank you.
EDIT: Constructor of the class that inherits ToolWindowPane:
public CpcObjectsWindow() : base(null)
{
this.Caption = "CPC Objects";
// This is the user control hosted by the tool window; Note that, even if this class implements IDisposable,
// we are not calling Dispose on this object. This is because ToolWindowPane calls Dispose on
// the object returned by the Content property.
this.Content = new CpcObjectsWindowControl();
this.ToolBar = new CommandID(new Guid(CpcExtensionPackage.guidCpcExtensionPackageCmdSet), CpcExtensionPackage.cpcObjectsToolbar);
this.ToolBarLocation = (int)VSTWT_LOCATION.VSTWT_TOP;
}
I tried to add search to a tool window , a search control appears at the top of the tool window.
I tried to search form the ToolWindowPane Class but there is not any property can set the size of search bar. I think that you can submit a feature request on DC.
I run often into many problems which leads to refactoring my code...
That is why I want to ask for some recommendations.
The problems I'm running into are:
1) Providing data to XAML
Providing simple data to control value instead of using a value converter. For instance I have a color string like "#FF234243" which is stored in a class. The value for the string is provided by a web application so I can only specify it at runtime.
2) UI for every resolution
In the beginnings of my learning I got told that you can create a UI for every possible resolution, which is stupid.
So I've written a ValueConverter which I bind on an element and as ConverterParameter I give a value like '300' which gets calculated for every possible resolution... But this leads to code like this...
<TextBlock
Height={Binding Converter={StaticResource SizeValue}, ConverterParameter='300'}
/>
3) DependencyProperties vs. NotifyProperties(Properties which implement INotifyPropertyChanged) vs. Properties
I have written a control which takes a list of value and converts them into Buttons which are clickable in the UI. So I did it like this I created a variable which I set as DataContext for this specific Control and validate my data with DataContextChanged but my coworker mentioned that for this reason DependencyProperties where introduced. So I created a DependecyProperty which takes the list of items BUT when the property gets a value I have to render the buttons... So I would have to do something like
public List<string> Buttons
{
get { return (List<string>)GetValue(ButtonsProperty); }
set
{
SetValue(ButtonsProperty, value);
RenderButtons();
}
}
// Using a DependencyProperty as the backing store for Buttons. This enables animation, styling, binding, etc...
public static readonly DependencyProperty ButtonsProperty =
DependencyProperty.Register("Buttons", typeof(List<string>), typeof(MainPage), new PropertyMetadata(""));
private void RenderButtons()
{
ButtonBar.Children.Clear();
ButtonBar.ColumnDefinitions.Clear();
if(Buttons != null)
{
int added = 0;
foreach (var item in Buttons)
{
var cd = new ColumnDefinition() { Width = new GridLength(1, GridUnitType.Star) };
var btn = new Button() { Content = item };
ButtonBar.ColumnDefinitions.Add(cd);
ButtonBar.Children.Add(btn);
Grid.SetColumn(btn, added);
}
}
}
And have to use it like this:
<Controls:MyControl
x:Name="ButtonBar" Button="{Binding MyButtons}">
</Controls:MyControl>
Since these are a lot of topics I could seperate those but I think that this is a pretty common topic for beginners and I have not found a got explanation or anything else
1. Providing data to XAML
There are two options: prepare data in the ViewModel or to use converter.
To my mind using converter is better since you can have crossplatform viewModel with color like you mentioned in your example and converter will create platform dependent color. We had similar problem with image. On android it should be converted to Bitmap class, while on UWP it's converted to BitmapImage class. In the viewModel we have byte[].
2. UI for every resolution
You don't need to use converter, since Height is specified in effective pixels which will suit all the required resolutions automatically for you. More info can be found at the following link:
https://learn.microsoft.com/en-us/windows/uwp/design/layout/layouts-with-xaml
There are two options how to deal with textblock sizes:
a) Use predefined textblock styles and don't invent the wheel (which is the recommended option):
https://learn.microsoft.com/en-us/windows/uwp/design/style/typography#type-ramp
Or
b) Specify font size in pixels. They are not pixels, but effective pixels. They will be automatically scaled on different devices:
https://learn.microsoft.com/en-us/windows/uwp/design/style/typography#size-and-scaling
Furthermore, use adaptive layout to have different Layout for different screen sizes.
3) DependencyProperties vs. NotifyProperties(Properties which implement INotifyPropertyChanged) vs. Properties
As per your code you can try to use ListView or ItemsControl and define custom item template.
DependencyProperties are created in DependencyObject and are accessible in xaml. All controls are inherited from DependencyObjects. Usually you create them when you want to set them in xaml. They are not stored directly in the objects, but in the global dictionary and resolved at runtime.
DependencyProperties were created long time ago and you can find lots of links which explain them in details:
http://www.wpftutorial.net/dependencyproperties.html
https://techpunch.wordpress.com/2008/09/25/wpf-wf-what-is-a-dependency-property/
When should I use dependency properties in WPF?
What is a dependency property? What is its use?
What is a dependency property?
INotifyPropertyChanged INPC are the central part of MVVM. You bind your view to viewModel which implements INPC and when you change value of the property control is notified and rereads the new value.
Download the following video in high resolution which explains MVVM in details (by Laurent Bugnion):
https://channel9.msdn.com/Events/MIX/MIX11/OPN03
MVVM: Tutorial from start to finish?
Normal properties are used in model classes or when there is no need to notify UI regarding changes.
I am making a simple game that (for the main part) consists of a Panel with a grid of 32 PictureBoxes inside, each with a BackgroundImage. You click on a "tile" and it flips revealing a picture. My problem is that when the Form Loads, I can see it drawing. I see the Panel .. then empty PictureBoxes, then finally it fills in the PictureBoxes with the BackgroundImages.
I've turned DoubleBuffer to True for the Form, and I've also added the following:
Private Sub UseDoubleBuffer()
Me.SetStyle(ControlStyles.AllPaintingInWmPaint Or ControlStyles.UserPaint Or ControlStyles.DoubleBuffer, True)
Me.UpdateStyles()
End Sub
Which I call when the Form Loads. I'm not sure what else I can do? I want it to just 'pop' onto the screen. Why isn't the DoubleBuffer working? Do I need to code the panel manually? I was trying to avoid that as it's obviously easier to just drag and drop into the Form, but if I need to, I will.
I can't post screenshots apparently, as my rep isn't high enough yet, but believe me, it looks hideous, and I do want to make this as sleek as I possible can. Any ideas?
Try creating flicker free custom panel controls:
Here are the steps to use this control:
1. Add new class "NonFlickerPanel" to your C# application.
2. Replace autogenerated class code with C# code shown below.
3. Use NonFlickerPanel object instead of Panel object in your application.
public partial class NonFlickerPanel : Panel
{
public NonFlickerPanel() : base()
{
this.SetStyle(ControlStyles.AllPaintingInWmPaint,
ControlStyles.UserPaint
ControlStyles.OptimizedDoubleBuffer,
true);
}
}
Try making the picture boxes invisible (.visible = false) until they're all loaded, then set visible to true for all of them.
I Build a scrollViewer and its elements in my ViewModel, and it's built into a property FrameworkElement PageElement I rebuild the pageElement every time some event happens, I want to bind the PageElement to a real scrollViewer in the View so that whenever I change pageElement, it draws itself in it's view.
Let me give you a little armchair advice. I don't know the details of your project but the details in your question make me draw a few conclusions.
First, to have your view model create UI elements is not wrong. But it is really unusual. It sounds like you might be missing the concept of data template or data template selector.
Using a data template allows you to have a rich presentation of data that is built as the individual record is generated and rendered in a repeater or in a single content control.
Using a data template selector allows you to have various different presentations of data that using code-behind logic will switch between based on data or other criteria.
Ref on templates: http://blog.jerrynixon.com/2012/08/windows-8-beauty-tip-using.html
Second, to have your UI be re-generated as the result of an event being raised sounds like a short path to performance problems.
Every time you manually create elements and add them to the visual tree, you put your app at risk of binding lag while the layout is re-rendered. Run your app on an ARM and I bet you may already see it. Then again, a simplistic UI may not suffer from this general rule of thumb.
Because I do not know the event, I cannot presume it is frequently occurring. However, if it is frequently occurring, then even a simplistic UI will suffer from this.
Now to answer your question
Sherif, there is no write-enabled property on a scrollviewer that will set the horizontal or vertical offset. The only way to set the offset of a scrollviewer is to call changeview().
var s = new ScrollViewer();
s.ChangeView(0, 100, 0);
You cannot bind to a method, so binding to something like this is a non-starter without some code-behind to read the desired offset and calling the method directly.
Something like this:
public sealed partial class MainPage : Page
{
MyViewModel _Vm = new MyViewModel();
ScrollViewer _S = new ScrollViewer();
public MainPage()
{
this.InitializeComponent();
this._Vm.PropertyChanged += (s, e) =>
{
if (e.PropertyName.Equals("Offset"))
_S.ChangeView(0, _Vm.Offset, 0);
};
}
}
public class MyViewModel : INotifyPropertyChanged
{
private int _Offset;
public int Offset
{
get { return _Offset; }
set
{
_Offset = value;
PropertyChanged(this, new PropertyChangedEventArgs("Offset"));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
But let me caution you. The offset will need to be based on something. And those variables may change based on the window size, the font size, scaling from transforms, and lots of other factors. The code above will work most of the time, but it will possible fail frequently on other devices.
So, what to do? My recommendation is that you code this in your code-behind, monitoring for whatever scenario you feel would require a scroll, and simply programmatically scroll it from bode-behind. Beware, though, programmatically scrolling a scrollviewer could make your UI confusing to the user.
You know your app. You will have to choose.
Best of luck!
I am trying to implement MVVM, and are having issues with moving LoadOnDemand to my ViewModel using triggers and RelayCommands, I have the event firing and all,
but as it turns out it is possible to expand a node in the tree without having it selected (i have databound the SelectedItem property in my ViewModel), thus breaking the logic, since the onLoad animation will continue to spin.
If I instead do this:
private void HierarchyTreeControl_LoadOnDemand(
Object sender,
Telerik.Windows.RadRoutedEventArgs e){
RadTreeViewItem clickedItem = null;
clickedItem = e.OriginalSource as RadTreeViewItem;
if (clickedItem != null) {
...do load logic
in the code behind file. I have access to the expanding item (clickedItem). What am I missing?
Is it possible to do some sort of binding on the ExandingItem?
Any Help will be appreciated :)
Since you are not using a standard treeview, I cannot be sure this is relevant. But I have previously had success in binding a TreeViewItem's IsExpanded property to a viewmodel property, in which I loaded items when the value was set to true (and not already loaded).
Here is a useful link: One more platform difference more-or-less tamed