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

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, я бы попробовал.