Я часто сталкиваюсь с множеством проблем, что приводит к рефакторингу моего кода ...
Вот почему я хочу попросить совета.
Проблемы, с которыми я сталкиваюсь:
1) Предоставление данных в XAML
Предоставление простых данных для управления значением вместо использования преобразователя значений. Например, у меня есть цветовая строка типа «# FF234243», которая хранится в классе. Значение строки предоставляется веб-приложением, поэтому я могу указать его только во время выполнения.
2) UI для каждого разрешения
В начале моего обучения мне сказали, что вы можете создать пользовательский интерфейс для любого возможного разрешения, что было глупо. Итак, я написал ValueConverter, который привязываю к элементу, и в качестве ConverterParameter я даю значение вроде «300», которое рассчитывается для каждого возможного разрешения ... Но это приводит к такому коду ...
<TextBlock
Height = {Binding Converter = {StaticResource SizeValue}, ConverterParameter='300'}
/>
3) DependencyProperties против NotifyProperties (свойства, реализующие INotifyPropertyChanged) против свойств
Я написал элемент управления, который принимает список значений и преобразует их в Кнопки, которые можно щелкнуть в пользовательском интерфейсе. Итак, я сделал это так, я создал переменную, которую я установил как DataContext для этого конкретного Контроль, и подтвердил свои данные с помощью DataContextChanged, но мой коллега упомянул, что по этой причине DependencyProperties был введен. Итак, я создал Зависимость, который принимает список элементов НО, когда свойство получает значение, которое я должен отображать для кнопок ... Поэтому мне пришлось бы сделать что-то вроде
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);
}
}
}
И использовать его нужно так:
<Controls:MyControl
x:Name = "ButtonBar" Button = "{Binding MyButtons}">
</Controls:MyControl>
Поскольку это много тем, я мог бы их разделить, но я думаю, что это довольно распространенная тема для новичков, и я не нашел объяснений или чего-то еще.
В 1-й задаче вы хотели избежать использования преобразователя значений и напрямую использовать шестнадцатеричную цветовую строку с элементом управления, не так ли? ... Шестнадцатеричная цветовая строка является свойством класса модели .. ??
@AshiqHassan да, это шестнадцатеричный цвет, но проблема в том, что пользователи могут установить его в веб-приложении, и в этом случае это не ARGB, а RGB, поэтому его не так просто зарегистрировать, поэтому я хотел бы использовать solidcolorbrush в качестве ресурса моей страницы а реальная ценность должна быть предоставлена классом
1. Предоставление данных в XAML
Есть два варианта: подготовить данные во ViewModel или использовать конвертер. На мой взгляд, использование конвертера лучше, поскольку у вас может быть кроссплатформенная модель viewModel с цветом, как вы упомянули в своем примере, и конвертер будет создавать зависимый от платформы цвет. У нас была аналогичная проблема с изображением. В Android он должен быть преобразован в класс Bitmap, а в UWP преобразован в класс BitmapImage. В viewModel у нас есть byte [].
2. Пользовательский интерфейс для каждого разрешения
Вам не нужно использовать конвертер, так как высота указывается в эффективных пикселях, которые автоматически подойдут для всех необходимых разрешений. Более подробную информацию можно найти по следующей ссылке:
https://docs.microsoft.com/en-us/windows/uwp/design/layout/layouts-with-xaml
Есть два варианта работы с размерами текстовых блоков:
а) Используйте предопределенные стили текстовых блоков и не изобретайте колесо (это рекомендуемый вариант):
https://docs.microsoft.com/en-us/windows/uwp/design/style/typography#type-ramp
Или
б) Укажите размер шрифта в пикселях. Это не пиксели, а эффективные пиксели. Они будут автоматически масштабироваться на разных устройствах:
https://docs.microsoft.com/en-us/windows/uwp/design/style/typography#size-and-scaling
Кроме того, используйте адаптивная верстка, чтобы иметь разный макет для разных размеров экрана.
3) DependencyProperties против NotifyProperties (свойства, реализующие INotifyPropertyChanged) против свойств
В соответствии с вашим кодом вы можете попробовать использовать Посмотреть список или ItemsControl и определить собственный шаблон элемента.
DependencyProperties создаются в DependencyObject и доступны в xaml. Все элементы управления унаследованы от DependencyObjects. Обычно вы создаете их, когда хотите установить их в xaml. Они хранятся не непосредственно в объектах, а в глобальном словаре и разрешаются во время выполнения.
DependencyProperties были созданы очень давно, и вы можете найти множество ссылок, которые подробно их объясняют:
http://www.wpftutorial.net/dependencyproperties.html
https://techpunch.wordpress.com/2008/09/25/wpf-wf-what-is-a-dependency-property/
Когда мне следует использовать свойства зависимостей в WPF?
Что такое свойство зависимости? Какая от этого польза?
Что такое свойство зависимости?
INotifyPropertyChanged INPC являются центральной частью MVVM. Вы привязываете свое представление к viewModel, который реализует INPC, и когда вы изменяете значение элемента управления свойством, уведомляется и перечитывает новое значение.
Загрузите следующее видео в высоком разрешении, в котором подробно объясняется MVVM (от Лорана Бугниона): https://channel9.msdn.com/Events/MIX/MIX11/OPN03
MVVM: Учебник от начала до конца?
Обычные свойства используются в классах моделей или когда нет необходимости уведомлять пользовательский интерфейс об изменениях.
Так как источников очень много, я постараюсь поискать их как можно скорее. Если я приму ваш ответ, следует ли разделить эти темы на 3 сообщения и связать их в описании, чтобы вы могли понять свою точку зрения, или мне следует сохранить его как одно сообщение, чтобы другие пользователи увидели, что это связанные вопросы?
Что касается представления списка в вопросе 3: Моя проблема заключалась в том, что я дал возможность установить индексы столбцов для кнопок, чтобы они могли быть двумя кнопками в одном месте, но были видны, а другая была свернута. Их состояние может быть изменено путем простого доступа к списку и установки их состояния вместо изменения всего списка и принудительного полного обновления пользовательского интерфейса. Но изменилось бы, если бы я просто изменил источник, как в работе, так и в обслуживании?
@MelloPs, если вы не удовлетворены ответом, вы можете разделить свой вопрос. В будущем не создавайте список вопросов, так как новые пользователи не смогут найти ответы, поскольку в вашем заголовке нет конкретных ключевых слов по вопросу.
@MelloPs, что касается третьего вопроса, иметь собственный элемент управления - это нормально, но свойство зависимости должно быть чем-то вроде списка команд, а не списка кнопок. Если вы посмотрите на реализацию ListView, у них есть не список элементов управления, а список данных (элементов) для элемента управления.
Сейчас я пытаюсь проработать TuTs, но этот ответ мне уже очень помог. Большое вам спасибо.
Каждая указанная тема должна быть отдельным вопросом о переполнении стека.