Комментарии 40
Картинок бы…
код бы лучше подсветить через source.virtser.net
По теме — продолжай изучать 8-) Статья хорошая, но много программизма и мало сильверлайта. Как бы соль системы в том, что она очень хорошо работает на декларативном уровне с анимацией и привязкой к данным. Можно было бы просто попробовать забиндить часы на лейбл. А тут подход с другого конца.
Кстати, посмотри на возможности Expression Blend, которая намного лучше студии работает с XAML и позволяет проворачивать интересные фокусы.
ps Демон, за что так гуглхром скукожил?
Кстати, посмотри на возможности Expression Blend, которая намного лучше студии работает с XAML и позволяет проворачивать интересные фокусы.
ps Демон, за что так гуглхром скукожил?
За «SizeChanged» хочется «пожурить», но я думаю исправите когда дойдёте до панелей.
Можно все-таки пожурить? :) Любопытно стало
Вы могли не подписываться на событие, что размеры окна изменились, а вставить ваш элемент в Grid(контейнер) и у этого элемента выставить Margin. Ещё можно с помощью того же грида разбить на 3 колонки, задать крайней левой и крайней правой относительные размеры, а центральной постоянный и в центральную положить контрол. Возможно пришлось бы немного подправить ваш код :).
Т.е. тогда получается, что вместо canvas надо использовать grid?
Делается все-таки компонент. Ему должно быть пофигу, во что он вставлен.
А ему и пофиг во что он вставлен. Только есть различия в принципах работы StackPanel, Grid, Canvas etc. Точнее в принципах работы компонентов при использовании контейнеров. Я считаю хорошей практикой, вместо того что бы подписываться на какое либо событие от родительского объекта, сделать так чтобы родительский объект сам выставлял необходимые ему данные. Да и строк кода тогда меньше с вашей стороны будет, что позволяет сделать работу программиста более продуктивной.
Представь, что canvas — это div с «position: absolute» и фиксированными размерами.
А такие структуры как grid/stackpanel/wrappanel (см. www.codeplex.com/Silverlight) — автоматически масштабируются.
Вы не обижайтесь, но созданный в статье контрол выглядит мягко говоря дико. Понятно, что по незнанию, но зачем людей пугать и путать?
Если говорить о деталях, то:
[TemplatePart(Name=Clocks.RootElement,Type=typeof(Canvas))]
в данном примере абсолютно бесполезно, а используется при создании контролов по принципу Parts&States. Если интересно, можно почитать здесь
функция CreateContent, создающая какие-то элементы. Зачем? Используйте тот самый generic.xaml, объявите ректы и тексты декларативно
А вообще, если вас интересуют часы, то загляните сюда, заодно посмотрите на MVP в действии.
Если говорить о деталях, то:
[TemplatePart(Name=Clocks.RootElement,Type=typeof(Canvas))]
в данном примере абсолютно бесполезно, а используется при создании контролов по принципу Parts&States. Если интересно, можно почитать здесь
функция CreateContent, создающая какие-то элементы. Зачем? Используйте тот самый generic.xaml, объявите ректы и тексты декларативно
А вообще, если вас интересуют часы, то загляните сюда, заодно посмотрите на MVP в действии.
Полностью поддерживаю. Я бы тоже использовал XAML для разметки, а не C#.
Хотелось сделать как можно больше c#-ом, а не xaml-ем
Ну, это так же как сказать что хочется больше сделать на том же C#, нежели HTML для веб-приложения. То есть — получается, что это just-4-fun.
Просто дело в том, что если проект будет сложнее, чем Hello World, плюс над ним будут работать больше 1 человека — будет крайне сложно понимать структуру документа. Недаром ведь все это придумали.
Я все это к тому, что лучше даже для наглядности ничего не отрицать, а использовать для задач соответствующие документы.
Просто дело в том, что если проект будет сложнее, чем Hello World, плюс над ним будут работать больше 1 человека — будет крайне сложно понимать структуру документа. Недаром ведь все это придумали.
Я все это к тому, что лучше даже для наглядности ничего не отрицать, а использовать для задач соответствующие документы.
Приехали :)
«документы» = «инструменты»
«документы» = «инструменты»
Согласен.
Но хочется как можно быстрее начать делать компоненты.
А компоненты в моем кастомном случае полностью програмные (anychart.com)
По привычке и сделал все кодом.
Но хочется как можно быстрее начать делать компоненты.
А компоненты в моем кастомном случае полностью програмные (anychart.com)
По привычке и сделал все кодом.
А компоненты в моем кастомном случае полностью програмные (anychart.com)
зря вы так… в WPF(Silverlight) очень многое можно сделать на уровне XAML. очень многое.
просто нужно приноровиться, но это приходитс опытом. набьете руку — почувствуете. но для этого надо руку набивать на XAML, а вы его избегаете
А даст ли он преймущества в:
1. размере выходного бинарника
2. скорости работы
По сравнению со сделаным руками?
1. размере выходного бинарника
2. скорости работы
По сравнению со сделаным руками?
1. Не думаю, что есть разница, ведь xaml вместе со всем остальным зиппуется.
2. Какая разница, создаются элементы при парсинге xaml или в коде…
Вообще же, я считаю что не использовать богатые возможности декларативного дизайна и databinding в WPF/Silverlight не рационально, они же созданы чтобы всем облегчить жизнь.
А насчет чартов… посмотрите на Silverlight toolkit, открытый проект с кодами, там есть ряд чарт-контролов, оцените как наглядно и изящно код может выглядеть на этой платформе.
2. Какая разница, создаются элементы при парсинге xaml или в коде…
Вообще же, я считаю что не использовать богатые возможности декларативного дизайна и databinding в WPF/Silverlight не рационально, они же созданы чтобы всем облегчить жизнь.
А насчет чартов… посмотрите на Silverlight toolkit, открытый проект с кодами, там есть ряд чарт-контролов, оцените как наглядно и изящно код может выглядеть на этой платформе.
После Adobe Flex у меня отвращение к «удобной xml-based разметке», так как получается слишком много ненужного говна.
И по перфомансу как то не жжет.
Проще руками все сделать. Не удобно, но гарантирован выигрыш в производительности и уж тем более в размере.
И по перфомансу как то не жжет.
Проще руками все сделать. Не удобно, но гарантирован выигрыш в производительности и уж тем более в размере.
«Лучший способ понять что-то, это объяснить это другому»
© Народная мудрость
тогда зачем навязывать свои методы другим?
многие отнесутся к вашей статье как к учебному материалу, а вы им изначально навязываете порочные (в контексте WPF/Silverlight) практики писать все руками и избегать XAML.
привесьте тогда уж вначале дисклэймер какой-нибудь, типа данная статья преследует академические цели написать все на голом c# и идет вразрез с WPF best practices или как там рекомендации называются :") чтобы сразу расставить точки над «ё» и не сбивать неофитов с пути истинного ;)
А даст ли он преймущества в:
1. размере выходного бинарника
2. скорости работы
По сравнению со сделаным руками?
а вы поэкспериментируйте ;)
потом подсобрав статистику оцените по размеру/быстродействию/скорости разработки/удоству поддержки и будете принимать решения в контексте свих проектов и требований.
для меня размер не критичен (узкозаточенный внутренний проект на WPF) и проблем со скоростью не вижу. поэтому основным критерием было удобство для разработчика. у вас всё может быть иначе поэтому советую проверять самому, а в целом разница имхо будет крайне незнаачительна в скорости и минимальна в размере. имхо
Народная мудрость в оригинале: «Учи других — и сам поймешь».
Это дефолтная «тема» компонента. В ней прописываем следующее:
<TextBlock>
<TextBlock.Text>Hello, World!</TextBlock.Text>
</TextBlock><ResourceDictionary
кажись кусок из первого листинга тут лишний ;)
кстати, а что мешало создать Clock.xaml примерно такого содержания и докодить логику в Clock.xaml.cs?
мне на самом деле интересно ибо сильверлайт не щупал и насколько оно отстало от WPF не представляю…
но по идее должно сработать не хуже вашего способа… или я не прав?
<UserControl x:Class="Clock"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
<!-- control code here -->
</UserControl>
* This source code was highlighted with Source Code Highlighter.мне на самом деле интересно ибо сильверлайт не щупал и насколько оно отстало от WPF не представляю…
но по идее должно сработать не хуже вашего способа… или я не прав?
из-за кармы оформить отдельным постом не могу, но на вообружение остальным(вдруг кто не знает):
вышла книга(в эл. варианте) «Введение в Silverlight 2» — полностью на русском языке
линк на скачку: https://msdb.ru/Downloads/expression/resources/IntroducingMicrosoftSilverlight2.pdf
PS: спасибо «Бюллетень-молния MSDN» )
вышла книга(в эл. варианте) «Введение в Silverlight 2» — полностью на русском языке
линк на скачку: https://msdb.ru/Downloads/expression/resources/IntroducingMicrosoftSilverlight2.pdf
PS: спасибо «Бюллетень-молния MSDN» )
rapidshare.de/files/41209028/IntroducingMicrosoftSilverlight2.pdf.html
залил на рапиду
залил на рапиду
Спасибо! Добавил в топик. И чуть чуть в меру своих сил поправил ситуацию с кармой :)
Написал «официальную новость» — habrahabr.ru/blogs/silverlight/47825/ :)
А вот правильная прямая ссылка — www.microsoft.com/rus/download.aspx?file=/expression/resources/IntroducingMicrosoftSilverlight2.pdf
А вот правильная прямая ссылка — www.microsoft.com/rus/download.aspx?file=/expression/resources/IntroducingMicrosoftSilverlight2.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Silverlight 2: Проба пера