Как написать свойство зависимости только для псевдо-записи?

Question

Хорошо, так что это просто идея, которая у меня всплыла в голове относительно своего рода свойства зависимости «только для псевдозаписи». Я говорю своего рода , потому что на самом деле я даже не хочу, чтобы значение хранилось, а скорее, я хочу, чтобы значение, которое я передаю установщику, установило другие свойства. В качестве гипотетического примера я хотел бы сделать это ...

<button UIHelper.Bounds="10,10,40,20" />

вместо этого ...

<button Canvas.Left="10" Canvas.Top="10" Width="40" Height="20" />

Просто удобная возможность печатать на XAML, которая позволяет мне задавать фактические четыре свойства с помощью чего-то более легкого для ввода благодаря, скажем, присоединенному свойству только для записи. Подумайте о сбитых правилах CSS. На самом деле, вот с другой стороны ...

<border UIHelper.BrushSpec="AliceBlue Red 2 4" />

вместо ...

<border Background="AliceBlue" BorderBrush="Red" BorderThickness="2" CornerRadius="4" />

Теперь, используя первый в качестве примера, одна идея состоит в том, чтобы сохранить такую ​​структуру внутри, а затем синхронизировать ее с существующими свойствами Width, Height, Canvas.Left и Canvas.Top, но я действительно никогда не планирую читать это обратно, так что не нужно. (Технически я мог бы полностью игнорировать его сохранение и просто вызывать ClearValue в обработчике с измененным свойством, но опять же, это не совсем для его считывания, так что это просто для согласованности.)

Технически, я даже не хочу / не хочу, чтобы это был DP, за исключением того, что я понимаю, что если вам нужно установить его из XAML, это должен быть DP, отсюда и я. Было бы замечательно, если бы мы могли просто установить прямое свойство .NET, так как я мог бы сделать и реализацию, и настройку, и реконструировать себя по мере необходимости, но, опять же, я понимаю, что вы не можете получить доступ к свойствам .NET из XAML, поэтому я ' м прямо здесь.

Теперь да, я знаю, что многие люди, особенно пуристы XAML, будут осуждать эту концепцию, но я спрашиваю как не почему , так что если по какой-то другой причине Считайте это упражнением «можно ли это сделать», а не «если это будет сделано». Я даже не предполагаю, что это то, что я буду использовать. Я просто пытаюсь лучше понять границы DP и XAML, и нахожу подобные упражнения очень полезными.

Итак, мысли ??

M

Answer 1

Не вдаваясь в крайности написания собственного компилятора XAML, я думаю, что лучшее, что вы можете сделать, - это присоединенное свойство, которое задает группу свойств, в которых вы заинтересованы, на основе определенного вами компактного синтаксиса. Да, это означает, что вы выделили хранилище для компактного представления, но, как вы сказали, вы можете сразу очистить его после применения. Это было бы немного неортодоксально, но технически это сработало бы.

Можно также вообще не объявлять поле присоединенного свойства, чтобы к значению обращались через методы get / set (не пробовал этого, но я считаю, что это работает, когда DP является частным, так что, возможно, это будет работать ). Таким образом, вы могли бы на самом деле сделать его читабельным, не беспокоясь о прослушивании изменений соответствующих свойств. Конечно, это означает, что в вашей собственности не будет уведомлений об изменениях:

public static string GetBounds(UIElement uiElement)
{
    return Canvas.GetLeft(uiElement) + "," + ...;
}

public static void SetBounds(UIElement uiElement, string compact)
{
    // parse and apply compact
}

Я просто помещаю компактное представление в string выше, но вы, вероятно, захотите использовать определенный тип. Опять же, приведенное выше может не работать - вам может понадобиться связанный экземпляр DependencyProperty. Если бы я был на компьютере с Windows, я бы попробовал.