Вы сами себе противоречите, не находите?

1. _FR>Что именно у меня не работает? "типичная поза программиста" — это не брать лишнего и обходиться минимально необходимым.
2. _FR>Но объяснения того, почему, при прочих равных, я должен предпочесть более derived класс я не увидел.

При отутствии противопоказаний всегда стоит выбирать more derived класс. Я не увидел ни одной причины, по которой вам следовало бы использовать FrameworkElement. Вы изпользуете фрейворк.



Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, DmitryMS, Вы писали:

DMS>>>>Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?
>>>>FR>Скорее, "на таком _низком_ уровне".
DMS>>>>Что за бред Имелось ввиду уровне [абстракции]. "Знание предмета на низком уровне" оставляем в пэтэушном прошлом
>>>>FR>А чем "базовее" базу выберешь, чем меньше классов в иерархии между тобой и выше будет, тем тем меньше будешь от этой самой базы зависеть.

DMS>>>> типичная поза программиста — фиг с ним, пусть не работает, но зато мощно и расширяемO

_FR>Что именно у меня не работает? "типичная поза программиста" — это не брать лишнего и обходиться минимально необходимым.

То, что должно работать без приложения каких бы то ни было усилий — фокус.

DMS>>Проблема в том что наледуюсь от высокоабстрактного обьекта вы взваливаете на себя кучу ответственности ,

_FR>Да что вы? И какую же именно ответственность я на себя взваливаю в этом конкретном случае? Что вы понимаете под "высокоабстрактного обьекта" и как это связано с "ответственностью"?

DMS>>плюс — нетипичный = непротестированный сценарий использования.

_FR>Среди кого "нетипичный"?

Судя по вашим вопросам, в первую очередь для вас.

DMS>>Вы просто можете не знать о необходимости перегрузки виртуального вызова, необходимого для корректной работы вашей имплементации

_FR>Заодно, напомните мне пожалуйста, какой-такой метод во FrameworkElement _обязательно_ должен быть переопределён?

Любой, о котором вы недостаочно знаете.

_FR>Я как-то привык читать документацию к классам, от которых наследуюсь. И мне требуются серьёздные основания что бы предпочесть наследование от более специализированного класса. Например в том, что касается иерархии FrameworkElement-a: наследники не просто дополняют базовую реализацию, а, в нагрузку, привносят и свою специфику. Каждый из наследников — свою собственную специфику. Если вы наследуетесь от того же Control-а и при этом не обращаете внимание на Template и не обрабатываете его — то вы не верно выбрали базовый класс — получили ненужный оверхед, ибо любой пользователь некоего Control-а вправе рассчитывать на то, что с помощью шаблона сможет на что-то повлиять.

В вашем случае оверхед выражался бы в работе фокуса out-of-the-box. well done

_FR>Нет, программист, наследующийся от этого компонента должен просто обладать достаточной квалификацией, что бы понимать, что происходит [как минимум] на этом уровне абстракции (а лучше — что происходит, как минимум, на уровне дальше). И если ни понимания, ни желания понять нету — действительно, лучше от класса не наследоваться :о) Но откуда у вас сведения о квалификации топикстартера, что бы так настоятельно советовать ему как быть? Он такого совета во-первых не просил, а во-вторых вполне здраво ответил

Автор:
Дата: 20.04.11

.

Вы ей не обладаете, я тоже.

DMS>>Наследоваться от FramworkElement's для своего визуального компонента (я не рассматриваю людей, предпочитающих наследоваться от object, на всякий случай — вдруг мощь где то утеряется?) смысла нет.

_FR>Дело хозяйское — от чего наследуетесь вы мне не важно. Но объяснения того, почему, при прочих равных, я должен предпочесть более derived класс я не увидел — как, не знгая, что именно я хочу реализовать в своём компоненте вы берёте на себя смелость указывать мне, от кого наследоваться И что же из этого вы предложите, повторю: не зная того, что за компонент я пишу?

Вы опытный программист, но при работе с фрейворками вопрос ставится ровно наоборот: зачем мне FrameworkElement когда есть more derived Control? Ни одной причины кроме мифического оверхеда приведено не было.

_FR>

_FR>If you intend to use FrameworkElement as a base class, you might want to first examine the existing derived classes. FrameworkElement provides support for a number of basic scenarios, but also lacks a number of features that are desirable for an "element" in the sense of a building block that you use to create user interface (UI) in Extensible Application Markup Language (XAML). For instance, a FrameworkElement does not define any true content model; FrameworkElement as a base class does not define a property that can create XAML child elements. In particular, you might want to look at Control and ContentControl.

_FR>Уверяю вас, я внимательно читаю документацию. И не вижу тут указаний наследоваться от чего-то конкретного и не наследоваться от FrameworkElement. Даже мой плохой английский позволяет понять, что тут нет никаких указаний, а лишь совет о том, _что чаще всего_ нужно в _типовых кейсах_.

Не сомневаюсь, но слон то бы и незамечен.

Извините что влезаю, но вы мыслите антисистемно. Если вам хочется занайтся непродуктивным исследование fair play to you. Есть небезизвестный деятель из майкрософта, накатавший оду про причину co-existance of FramworkElement & FrameworkContentElement, вместо того чтобы признать — мы обосрались, please accept our applogies.

Вам определенно стоит его почитать дляупрочения доказательной базы.

Здравствуйте, DmitryMS, Вы писали:

DMS>Извините что влезаю, но вы мыслите антисистемно. Если вам хочется занайтся непродуктивным исследование fair play to you. Есть небезизвестный деятель из майкрософта, накатавший оду про причину co-existance of FramworkElement & FrameworkContentElement, вместо того чтобы признать — мы обосрались, please accept our applogies.

DMS>Вам определенно стоит его почитать дляупрочения доказательной базы.

Спасибо, ваша доказательная база в моих коментариях действительно не нуждается. Остаётся надеяться, что и другим это видно.

Здравствуйте, _FRED_, Вы писали:

_FR>Написав такие слова авторитетный, к коим вас причисляю, эрэсдээновец должен быть уверен, что иных кейсов, кроме как перечисленных им, у оппоненты быть не может А их у меня есть

Так я ж потенциальные кейсы привёл в цитате. И, имхо, чтобы за такие кейсы браться надо матчасть знать от и до, иначе только хуже выйдет Я например, щас за рендер не возьмусь — неделю надо будет копаться в книжках/примерах чтоб освежить всё в памяти.

_FR>Задумайтесь сами — перекрывает ли вышеотквоченное всё то многообразие, что может понадобится в жизни? Неужели скудный набор имеющихся наследников FrameworkElement может удовлетворить самые взыскательные, кои предъявляю я, требования? Ну-ну

Нет конечно. Но 99.(9)% custom controls можно (и нужно) наследовать от Control/UserControl.

Сделать "правильный" фокус — весьма нетривиальная задача. Я что-то не могу себе представить общеупотребительную ситуацию, когда требуется в одном классе и хитрый рендер, и интерактив, да ещё это общий случай + настолько тяжёлый, что оправдывает переписывание Control.

+ _сам_ класс Control очень мелкий, но нашпигован нюансами аля

internal void ChangeValidationVisualState(bool useTransitions)
{
    if (!Validation.GetHasError(this))
    {
        VisualStateManager.GoToState(this, "Valid", useTransitions);
        return;
    }
    if (base.IsKeyboardFocused)
    {
        VisualStateManager.GoToState(this, "InvalidFocused", useTransitions);
        return;
    }
    VisualStateManager.GoToState(this, "InvalidUnfocused", useTransitions);
}

Что нам как бы намекает — полноценно сымитировать поведение контрола — дело неблагодарное

Здравствуйте, Sinix, Вы писали:

_FR>>Написав такие слова авторитетный, к коим вас причисляю, эрэсдээновец должен быть уверен, что иных кейсов, кроме как перечисленных им, у оппоненты быть не может А их у меня есть

S>Так я ж потенциальные кейсы привёл в цитате. И, имхо, чтобы за такие кейсы браться надо матчасть знать от и до, иначе только хуже выйдет Я например, щас за рендер не возьмусь — неделю надо будет копаться в книжках/примерах чтоб освежить всё в памяти.

Вы спорите за что? за то, что "иногда можно наследоваться от контрола" или за то что "нет и не может быть причин наследоваться от FrameworkElement"? Я — против второго.

В некоторых случаях очень удобно написать наследника класса Control, но это далеко не все потребности покрывает. Даже сами фреймворкописатели наплодили много наследников FrameworkElement и каждый с какой-то определённой целью. Так что мешает реализовать некую неучтённую авторами фреймворка цель мне так же унаследовавшить от FrameworkElement?

_FR>>Задумайтесь сами — перекрывает ли вышеотквоченное всё то многообразие, что может понадобится в жизни? Неужели скудный набор имеющихся наследников FrameworkElement может удовлетворить самые взыскательные, кои предъявляю я, требования? Ну-ну
S>Нет конечно. Но 99.(9)% custom controls можно (и нужно) наследовать от Control/UserControl.

Вы видели сколько наследников у FrameworkElement? Panel является по вашему "custom controls"? Если "да", то почему же она не унаследована от "Control/UserControl"? Если "нет", то должны понимать, что помимо "custom controls" бывают и другие и я ни о каких "custom controls" не говорил Вот ещё TextBlock — если бы такого небыло бы стандартного, от кого бы вы порекомендовали мне унаследовать свой? От Panel? От Control? От UserControl?

S>Сделать "правильный" фокус — весьма нетривиальная задача. Я что-то не могу себе представить общеупотребительную ситуацию, когда требуется в одном классе и хитрый рендер, и интерактив, да ещё это общий случай + настолько тяжёлый, что оправдывает переписывание Control.

Control — это далеко не только фокус. И получать в нагрузку к чему-то одному ещё килогоамм ненужного некчему. На счёт тривиальности — сложно ли написать свою кастомную панель? Это каждый может сам за себя решить.

S>+ _сам_ класс Control очень мелкий, но нашпигован нюансами аля

S>internal void ChangeValidationVisualState(bool useTransitions)
S>{
S>    if (!Validation.GetHasError(this))
S>    {
S>        VisualStateManager.GoToState(this, "Valid", useTransitions);
S>        return;
S>    }
S>    if (base.IsKeyboardFocused)
S>    {
S>        VisualStateManager.GoToState(this, "InvalidFocused", useTransitions);
S>        return;
S>    }
S>    VisualStateManager.GoToState(this, "InvalidUnfocused", useTransitions);
S>}

S>Что нам как бы намекает — полноценно сымитировать поведение контрола — дело неблагодарное

А кто вам сказал, что кому-то нужно "полноценно" ИМХО, именно от непонимания того, что там творится, рождаетсмя болезнь "это делать не нужно"

Здравствуйте, _FRED_, Вы писали:

_FR>Вы спорите за что? за то, что "иногда можно наследоваться от контрола" или за то что "нет и не может быть причин наследоваться от FrameworkElement"? Я — против второго.

Я вроде как не собирался спорить. Всего лишь намекнул, что экономия на спичках без веских на то оснований приведёт к куда большим затратам на реализацию уже готового функционала. Почему это было воспринято (если было, конечно) как наезд —

_FR>Так что мешает реализовать некую неучтённую авторами фреймворка цель мне так же унаследовавшить от FrameworkElement?

Ничего. Я что-то не понимаю, у нас речь идёт о наследовании от FE ради избавления от "оверхеда", или о том, что от FE можно наследоваться в весьма специфических случаях? Я возражал исключительно против первого.

_FR>Вы видели сколько наследников у FrameworkElement? Panel является по вашему "custom controls"?
И как часто вы вводите в фреймворк фундаментально новые штуки? Если требуется панель — почему нельзя от неё унаследоваться? И как часто нам требуется одновременно наследование именно от FE _и_ поддержка фокуса?
Плиз, приведите хоть один практический пример.

_FR>А кто вам сказал, что кому-то нужно "полноценно" ИМХО, именно от непонимания того, что там творится, рождаетсмя болезнь "это делать не нужно"

Не, погодите! Или мы достаточно квалифицированы, чтобы лезть в дебри wpf (зачем _официально_ предлагается наследоваться от FE было в цитате выше), или мы делаем тяп-ляп контрол и в таком случае нам тем более пофиг, от чего наследоваться. И, раз уж топикстартеру _уже_ нужен функционал из Control — зачем играть в луддитов?

Здравствуйте, Sinix, Вы писали:

_FR>>Вы спорите за что? за то, что "иногда можно наследоваться от контрола" или за то что "нет и не может быть причин наследоваться от FrameworkElement"? Я — против второго.
S>Я вроде как не собирался спорить. Всего лишь намекнул, что экономия на спичках без веских на то оснований приведёт к куда большим затратам на реализацию уже готового функционала. Почему это было воспринято (если было, конечно) как наезд —

На счёт "без веских на то оснований" небыло распаршено :о) Да и в чём цимес меряться "наездами"? Это было воспринято как возражение на то, что могут быть причины наследаваться от FrameworkElement. И видеть в ответ на это причины, по которым принято наследоваться от FrameworkElement странно.

_FR>>Так что мешает реализовать некую неучтённую авторами фреймворка цель мне так же унаследовавшить от FrameworkElement?
S>Ничего. Я что-то не понимаю, у нас речь идёт о наследовании от FE ради избавления от "оверхеда", или о том, что от FE можно наследоваться в весьма специфических случаях? Я возражал исключительно против первого.

В моём сообщении

Автор: _FRED_
Дата: 20.04.11

, на которое был дан ответ, нет ни слова о "у нас речь идёт о наследовании от FE ради избавления от "оверхеда"" А о том, на сколько большим оверхедом для топикстартера окажется то, что он задумал, опять же не нам судить. Нам очень сложно учесть все его кейсы и полностью его ситуацию и что бы возражать в таких остоятельствах треюбуется доказать, что нет таких кейсов, которые стоили бы наследования от FrameworkElement. Мне кажется, доказать такое будет затруднительно. По крайней мере, советы из MSDN не звучат убедительно.

Здравствуйте, DmitryMS, Вы писали:

DMS>kod kin'te

public class Cell : FrameworkElement
    {
        protected VisualCollection m_оbjectChildrenList;
        DrawingVisual m_visual;

        public static readonly DependencyProperty IsTabStopProperty;
        public static readonly DependencyProperty TabIndexProperty;


        static Cell()
        {
            IsTabStopProperty = KeyboardNavigation.IsTabStopProperty.AddOwner(typeof(Cell));
            TabIndexProperty = KeyboardNavigation.TabIndexProperty.AddOwner(typeof(Cell));

        }

        public Cell()
        {
            // к примеру тут рисуется какой-то элемент
            m_visual = new DrawingVisual();
            DrawingContext dc = m_visual.RenderOpen();
            dc.DrawRectangle(Brushes.Black, new Pen(Brushes.Green, 5), new Rect(0, 0, 200, 300));
            dc.Close();
            m_оbjectChildrenList = new VisualCollection(this);
            m_оbjectChildrenList.Add(m_visual);
            this.Loaded += new RoutedEventHandler(Cell_Loaded);
            this.Focusable = true;
        }

        public bool IsTabStop
        {
            get
            {
                return (bool)base.GetValue(IsTabStopProperty);
            }
            set
            {
                base.SetValue(IsTabStopProperty, value);
            }
        }

        public int TabIndex
        {
            get
            {
                return (int)base.GetValue(TabIndexProperty);
            }
            set
            {
                base.SetValue(TabIndexProperty, value);
            }
        }

        protected override void OnMouseDown(MouseButtonEventArgs e)
        {
            this.Focus();
        }

        void Cell_Loaded(object sender, RoutedEventArgs e)
        {
            Panel panel = this.Parent as Panel;
            FocusManager.SetFocusedElement(panel, this);
            FocusManager.SetIsFocusScope(this, true);
            this.Height = panel.ActualHeight;
            this.Width = panel.ActualWidth;
        }

        protected override int VisualChildrenCount
        {
            get
            {
                return m_оbjectChildrenList.Count;
            }
        }

        protected override Visual GetVisualChild(int index)
        {
            return m_оbjectChildrenList[index];
        }      
    }
}

<Window x:Class="MyControls.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:Control="clr-namespace:MyControls.Cell"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Control:Cell IsTabStop="True" TabIndex="4"/>
        <Button Height="20" Width="50" HorizontalAlignment="Left" TabIndex="5"/>
        <Button Height="20" Width="50" HorizontalAlignment="Right" TabIndex="3"/>
    </Grid>
</Window>

В итоге на мой элемент фокус приходит в последнюю очередь, хотя должен быть между кнопками.

Здравствуйте, _FRED_, Вы писали:

_FR>В моём сообщении

Автор: _FRED_
Дата: 20.04.11

, на которое был дан ответ, нет ни слова о "у нас речь идёт о наследовании от FE ради избавления от "оверхеда"" А о том, на сколько большим оверхедом для топикстартера окажется то, что он задумал, опять же не нам судить. Нам очень сложно учесть все его кейсы и полностью его ситуацию и что бы возражать в таких остоятельствах треюбуется доказать, что нет таких кейсов, которые стоили бы наследования от FrameworkElement. Мне кажется, доказать такое будет затруднительно. По крайней мере, советы из MSDN не звучат убедительно.

Я просто изучаю тонкости WPF(область попадания, Visual, стили, шаблоны) и решил воссоздать свой элемент(конечно урезанный). Появились трудности с фокусом и решил обратиться к Вам за помощью.

Здравствуйте, v.makeev, Вы писали:

VM>Обрабатывает клавишу TAB абсолютно корректно. Возможно, какие-то составные части вашего элемента тоже пытаются обработать TAB.

проблема была в следующем

Автор:
Дата: 20.04.11

VM>WpfInspector вам в помощь

Спасибо за софт — очень хороший!

Здравствуйте, Аноним, Вы писали:

_FR>>В моём сообщении

Автор: _FRED_
Дата: 20.04.11

, на которое был дан ответ, нет ни слова о "у нас речь идёт о наследовании от FE ради избавления от "оверхеда"" А о том, на сколько большим оверхедом для топикстартера окажется то, что он задумал, опять же не нам судить. Нам очень сложно учесть все его кейсы и полностью его ситуацию и что бы возражать в таких остоятельствах треюбуется доказать, что нет таких кейсов, которые стоили бы наследования от FrameworkElement. Мне кажется, доказать такое будет затруднительно. По крайней мере, советы из MSDN не звучат убедительно.

А>Я просто изучаю тонкости WPF(область попадания, Visual, стили, шаблоны) и решил воссоздать свой элемент(конечно урезанный). Появились трудности с фокусом и решил обратиться к Вам за помощью.

Очень правильно сделали. Не просто представить все сложности "фокусов" не попробовав сделать их самостоятельно А на дебаты влкруг не обращайте слишком много внимания :о)

Здравствуйте, _FRED_, Вы писали:

_FR>На счёт "без веских на то оснований" небыло распаршено :о)

Ок, будем тщательнее придумывать дисклаймеры

Кроме шуток, вы серьезно решили написать свою систему фокуса для того чтобы избежать овехеда вызванного использованием Control? Если это так, то посоветовать что либо вам мне, увы, нечего У дачи!

Здравствуйте, Аноним, Вы писали:

Решение оказалось следующее: нужно было убрать следующие две строчки

void Cell_Loaded(object sender, RoutedEventArgs e)
{
    Panel panel = this.Parent as Panel;
    // FocusManager.SetFocusedElement(panel, this);
    // FocusManager.SetIsFocusScope(this, true);
    this.Height = panel.ActualHeight;
    this.Width = panel.ActualWidth;
}

Здравствуйте, DmitryMS, Вы писали:

DMS>Кроме шуток, вы серьезно решили написать свою систему фокуса для того чтобы избежать овехеда вызванного использованием Control? Если это так, то посоветовать что либо вам мне, увы, нечего У дачи!

Нет, не решил

Автор:
Дата: 20.04.11