Как разрешить связанный объект от bindingexpression с WPF?
include_once ('../../../ wp-config.php');
global $ wpdb;
$ password = wp_hash_password ("ваш пароль" ); [/ д2]
4 ответа
Ниже представлена быстрая реализация метода расширения, который сделает именно то, что вы ищете. Я тоже не нашел ничего связанного с этим. Приведенный ниже метод всегда будет возвращать null, если по какой-либо причине значение не может быть найдено. Метод не будет работать, если путь включает []. Надеюсь, это поможет!
public static T GetValue<T>(this BindingExpression expression, object dataItem)
{
if (expression == null || dataItem == null)
{
return default(T);
}
string bindingPath = expression.ParentBinding.Path.Path;
string[] properties = bindingPath.Split('.');
object currentObject = dataItem;
Type currentType = null;
for (int i = 0; i < properties.Length; i++)
{
currentType = currentObject.GetType();
PropertyInfo property = currentType.GetProperty(properties[i]);
if (property == null)
{
currentObject = null;
break;
}
currentObject = property.GetValue(currentObject, null);
if (currentObject == null)
{
break;
}
}
return (T)currentObject;
}
Для людей в будущем, которые сталкиваются с этим вопросом:
Когда .NET 4.5 станет доступным, он будет иметь ряд новых свойств в BindingExpression, чтобы значительно упростить то, что вы ищете.
ResolvedSource - Объект, к которому на самом деле привязывается, полезно, когда у вас есть источник привязки, такой как 'grandparent.parent.me.Name'. Это вернет объект «я».
ResolvedSourcePropertyName - Имя свойства в ResolvedSource, к которому привязан. В случае выше, «Имя».
Аналогичным образом, будет Target и TargetName .
С помощью этих вспомогательных свойств в BindingExpression вы можете использовать более короткое и гораздо более простое отражение, которое с большей вероятностью будет работать в экстремальных ситуациях (индексаторы).
Я полагаю, что это другое решение StackOverflow , опубликованное здесь , также может работать для вас.
Скопированный блок кода для справки, прочитайте оригинальный пост для более подробной информации, предоставленной Томасом Левеском.
public static class PropertyPathHelper
{
public static object GetValue(object obj, string propertyPath)
{
Binding binding = new Binding(propertyPath);
binding.Mode = BindingMode.OneTime;
binding.Source = obj;
BindingOperations.SetBinding(_dummy, Dummy.ValueProperty, binding);
return _dummy.GetValue(Dummy.ValueProperty);
}
private static readonly Dummy _dummy = new Dummy();
private class Dummy : DependencyObject
{
public static readonly DependencyProperty ValueProperty =
DependencyProperty.Register("Value", typeof(object), typeof(Dummy), new UIPropertyMetadata(null));
}
}
Просто для дополнительной информации, PropertyPath разрешение обрабатывается внутренним классом MS под названием PropertyPathWorker, который живет в PresentationFramework под MS.Internal.Data. Если вы откроете его в Reflector, вы увидите, что он довольно сложный, поэтому я бы не рекомендовал пытаться дублировать его функциональность. Он тесно связан с общей архитектурой Binding.
Наиболее надежным способом поддержки синтаксиса всех путей свойств - включая свойства прикрепленных зависимостей и иерархический обход - является, вероятно, создание фиктивного зависимого объекта DependencyObject с зависимостями (DependencyProperty). Затем можно создать привязку из пути "владельца" к фиктивному свойству зависимостей, создать новое выражение BindingExpression, а затем вызвать выражение UpdateTarget. Это довольно тяжелый способ выполнения того, что, на первый взгляд, выглядит как простая задача, но я думаю, что есть много скрытых ловушек в том, как пути свойств разрешаются для привязки.
.