>>Элементом UI в WPF могут быть только классы, наследуемые от DependencyObject
Вы противоречите сами себе, вижу дальше смысла разъяснять мне что-либо нет, но все же я продолжу…
неужели?, ведь:
if (typeOf(UIElement) is DependencyObject && typeOf(ContentElement) is DependencyObject)
{
try
{
/*любой UI-элемент, который Вы создадите, будет базироваться на вышеперечисленных
* т.к. будет использоваться PresentationFramework
* который в свою очередь построен вокруг DependencyObject
*/
}
catch (Exception) { }
finally
{
//надеюсь моя логика теперь понятна?
}
}
>>в-третьих, заранее прошу прощения, Вы вообще представляете, почему WPF оперирует классами, унаследованными от DispatcherObject?
Еще как, но, казалось бы, при чем здесь это?
это я для того интересуюсь, чтобы узнать есть ли у Вас представление о WPF, включая не только namespace System.Windows.Controls.
ведь, Вы с самого начала полезли в дебри UIElement, привели пример Measure()/MeasureCore() и Arrange()/ArrangeCore().
для чего это? обсуждение же касалось именно FlowDocument и элементов внутри них. здесь невозможно относительное позиционирование относительно (извиняюсь за тавтологию) предшествующих и следующих элементов в общем потоке.
поэтому и в посте приводится решение данной проблемы.
и также цитируя Вас:
>>вижу дальше смысла разъяснять мне что-либо нет
Классы, наследуемые от DependencyObject являются «объектами зависимостей», позволяющий реализовывать такие вещи, как свойства зависимостей и маршрутизируемые события. Данные вещи, конечно, больше применимы к элементам, но ничто не мешает использовать их в какой-нибудь сторонней логике (например привязка данных, хотя для этого лучше реализовывать INotifyPropertyChanged).
Спасибо, знал и без Вас.
Так к чему все это. Классы, наследуемые от DependencyObject, не являются элементами. По вашей логике DispatcherObject также будет являться элементом.
в-нулевых, не по моей логике, т.к. я указал одну тонкую вещь: класс DependencyObject, но не DispatcherObject. Все-таки DispatcherObject живет и сам по себе.
во-первых, если посмотреть на все унаследованные классы от DependencyObject, то получится, что не существует ни одного элемента UI, котрый бы стоял особняком.
во-вторых, если необходимо создать свой собственый контрол, от какого базового класса Вы будете наследовать? правильно, либо от UIElement, либо от ContentElement.
в-третьих, заранее прошу прощения, Вы вообще представляете, почему WPF оперирует классами, унаследованными от DispatcherObject?
>>Run обладает отличительным свойством: Вы можете его использовать вместе UIElement.
В данном случае таким свойством обладают все классы, наследуемые от Object…
Ну это просто XamlReader вызывает метод ToString() у любого класса, ему незнакомого для построения UI.
>>Run обладает отличительным свойством: Вы можете его использовать вместе UIElement.
С таким же успехом можно использовать <sys:String>меня можно прочитать</sys:String>, и текст будет читаем.
Имелось ввиду то обстоятельтсво, что не каждый класс из System.Windows.Documents можно смело использовать как контент для элементов UIElement.
Уместнее было бы «потоковая компоновка».
«потоковая компоновка» — она же Flow Layout. Собственно об этом и речь, но с одной оговоркой: пост посвящен тому, чтобы использовать подобно FixedDocument, realtive positioning.
Понятно;) Согласен с Вами насчет насильного запихивания, однако в последнее время многие вендоры стараются делать все и вся именно на JS. Взять хотя бы Google с Chrome OS и HP с WebOS. При текущей ситуации создание и далее поддержка, скажем, млн. строк кода на JS станет гораздо труднее и неповоротливее, чем сейчас.
Вы имеет ввиду элементы UI — контролы. в данном случае Measure()/MeasureCore() и Arrange()/ArrangeCore() и необходимы layout manger'у WPF, чтобы позиционировать контролы в окне и родительском элементе.
Элементом UI в WPF могут быть только классы, наследуемые от DependencyObject, а т.к. inline-элементы (Run, Span, Bold и т.д.) и block-элементы (Paragraph, Section и т.д.) также наследники DependencyObject, следовательно, они также элементы WPF.
Относительную компоновку я имел ввиду внутри FlowDocument, но не обычного окна.
P.S.
Run обладает отличительным свойством: Вы можете его использовать вместе UIElement.
>>Span, Run, Paragraph
>>Таковыми не являются
выходит между нами недопонимание.
цитата из MSDN
Элементы Paragraph, List, ListItem и Bold используются для управления форматированием содержимого в зависимости от их порядка в разметке. Например, элемент Bold охватывает только часть текста в абзаце; в результате только эта часть текста будет выделена жирным шрифтом. Пользователям HTML это поведение будет знакомо.
я имею ввиду элементы самого FlowDocument типа Span, Run, Paragrapgh и т.п. position: relative — это из CSS.
и, вообще, не FlowDocumentViewer, а FlowDocumentReader; причем существуют еще и FlowDocumentPageViewer и RichTextBox, вместе с FlowDocumentScrollViewer.
в том-то и дело, что как только появился нормальный планшет, Apple сразу подала на производителя в суд.
если брать, как Вы говорите, и рассматривать, начиная с коробки, то
1. ОС Android, не iOS
2. на задней крышке везде логотипы Samsung, Google, а не нечто другое, походящее на Apple
3. побольше портов на боках
4. точно отсутствует знаменитая круглая кнопка, присущая и iPhone, и др. продуктам
5. рассматривая патенты, также ничего путного: да, в Android есть места нарушений (менее 10), однако это не относится конкретно к Galaxy Tab, но и к др. устройствам
мне вот интересно, как работают в других секторах рынка: ведь у плазменных телевизоров дизайн совпадает на 99%, дизайн LCD-мониторов — то же самое…
как по другому должен выглядеть планшет? треугольник, многоугольник, либо вообще с CRT-экраном!?
поэтому в реальных приложениях, обычно необходимо выводить пользователю предупреждение, либо заранее через ajax post-запросом отправить данные на сервер и как-то их сохранить.
а в-минус-первых, главная цель гугла: забаррикадировать свой поисковый бизнес с сопутствующими сервисами от любого рода нападок.
а любого рода нападки возможны только со стороны всех софтверных компаний с более большим возрастом на рынке (читаем MS между строк).
поэтому лучше унести землю из-под их ног. ведь лучшая защита — это атака. тому подтверждение Docs, GMail, Chrome, Android.
однако, мы говорим про сами языки и их компиляторы как таковые. а все делать руками и изощряться там, где обычно это и не ожидается, для достижения максимальной производительности, то это не приведет нас к
Удобство разработки. Будет сохранена динамическая, лёгкая в освоении, не требующая компиляции природа Javascript, которая сделала веб-платформу абсолютным лидером среди программистов-любителей.
что никак не вяжется с просмотром сгенерированного ассемблерного кода и т.д.
представьте, чтобы каждый JS-программист разбирался в таких тонкостях, да еще и для каждого браузера отдельно.
неужели?, ведь:
это я для того интересуюсь, чтобы узнать есть ли у Вас представление о WPF, включая не только namespace System.Windows.Controls.
ведь, Вы с самого начала полезли в дебри UIElement, привели пример Measure()/MeasureCore() и Arrange()/ArrangeCore().
для чего это? обсуждение же касалось именно FlowDocument и элементов внутри них. здесь невозможно относительное позиционирование относительно (извиняюсь за тавтологию) предшествующих и следующих элементов в общем потоке.
поэтому и в посте приводится решение данной проблемы.
и также цитируя Вас:
>>вижу дальше смысла разъяснять мне что-либо нет
Спасибо,
знал и без Вас.в-нулевых, не по моей логике, т.к. я указал одну тонкую вещь: класс DependencyObject, но не DispatcherObject. Все-таки DispatcherObject живет и сам по себе.
во-первых, если посмотреть на все унаследованные классы от DependencyObject, то получится, что не существует ни одного элемента UI, котрый бы стоял особняком.
во-вторых, если необходимо создать свой собственый контрол, от какого базового класса Вы будете наследовать? правильно, либо от UIElement, либо от ContentElement.
в-третьих, заранее прошу прощения, Вы вообще представляете, почему WPF оперирует классами, унаследованными от DispatcherObject?
Ну это просто XamlReader вызывает метод ToString() у любого класса, ему незнакомого для построения UI.
Имелось ввиду то обстоятельтсво, что не каждый класс из System.Windows.Documents можно смело использовать как контент для элементов UIElement.
«потоковая компоновка» — она же Flow Layout. Собственно об этом и речь, но с одной оговоркой: пост посвящен тому, чтобы использовать подобно FixedDocument, realtive positioning.
просто под революционным имел ввиду по сравнению с EcmaScript 3.
даже конкретизирую вопрос: чем ООП на классах хуже ООП на прототипах?
Элементом UI в WPF могут быть только классы, наследуемые от DependencyObject, а т.к. inline-элементы (Run, Span, Bold и т.д.) и block-элементы (Paragraph, Section и т.д.) также наследники DependencyObject, следовательно, они также элементы WPF.
Относительную компоновку я имел ввиду внутри FlowDocument, но не обычного окна.
P.S.
Run обладает отличительным свойством: Вы можете его использовать вместе UIElement.
>>Таковыми не являются
выходит между нами недопонимание.
цитата из MSDN
и, кстати, посмотрите на автомобили 20-х годов XX века:
Mercedes Mannheim 370 vs Ford A vs Horch 780
position: relative — это из CSS.
и, вообще, не FlowDocumentViewer, а FlowDocumentReader; причем существуют еще и FlowDocumentPageViewer и RichTextBox, вместе с FlowDocumentScrollViewer.
если брать, как Вы говорите, и рассматривать, начиная с коробки, то
1. ОС Android, не iOS
2. на задней крышке везде логотипы Samsung, Google, а не нечто другое, походящее на Apple
3. побольше портов на боках
4. точно отсутствует знаменитая круглая кнопка, присущая и iPhone, и др. продуктам
5. рассматривая патенты, также ничего путного: да, в Android есть места нарушений (менее 10), однако это не относится конкретно к Galaxy Tab, но и к др. устройствам
как по другому должен выглядеть планшет? треугольник, многоугольник, либо вообще с CRT-экраном!?
добиться эффекта как со страницы примера, через margin не получится никак
а любого рода нападки возможны только со стороны всех софтверных компаний с более большим возрастом на рынке (читаем MS между строк).
поэтому лучше унести землю из-под их ног. ведь лучшая защита — это атака. тому подтверждение Docs, GMail, Chrome, Android.
что никак не вяжется с просмотром сгенерированного ассемблерного кода и т.д.
представьте, чтобы каждый JS-программист разбирался в таких тонкостях, да еще и для каждого браузера отдельно.