Фокус ввода
От: Аноним  
Дата: 19.04.11 13:04
Оценка:
Создаю свой элемент:

public class MyElement : FrameworkElement
{
   // .........
}


Как можно реализовать возможность фокуса ввода? this.Focus() возвращает всегда false. И даже когда свойству this.Focusable присваиваю true, то все равно this.Focus() равен false.
Значения свойств после this.Focusable = true;
this.Focusable == true
this.IsEnabled == true
this.IsFocused == true
this.IsKeyboardFocused == false
this.Focus() == false

Статический метода Keyboard.Focus(this) возвращает null
Re: Фокус ввода
От: v.makeev Россия  
Дата: 19.04.11 17:30
Оценка:
Здравствуйте, Аноним

А вы добавили свой элемент в визуальное дерево? (something.AddVisualChild(myElement))
Если нет, то следующий код абсолютно законно вернет a == false и b == null.

var myElement = new MyElement {Focusable = true, IsEnabled = true};
var a = myElement.Focus();
var b = Keyboard.Focus(myElement);
Re[2]: Фокус ввода
От: Аноним  
Дата: 20.04.11 06:38
Оценка:
Здравствуйте, v.makeev, Вы писали:

VM>Здравствуйте, Аноним


VM>А вы добавили свой элемент в визуальное дерево? (something.AddVisualChild(myElement))

VM>Если нет, то следующий код абсолютно законно вернет a == false и b == null.

VM>
VM>var myElement = new MyElement {Focusable = true, IsEnabled = true};
VM>var a = myElement.Focus();
VM>var b = Keyboard.Focus(myElement);
VM>



Да-да, я добавлял в визуальное дерево. Проблема была в том, что я myElement.Focus() вызывал в конструкторе, а не в событие Loaded
Теперь все работает. Спасибо!
Re[3]: Фокус ввода
От: Аноним  
Дата: 20.04.11 12:14
Оценка:
Теперь другая проблема получилась. На панели отобразил свой элемент и кнопку. По умолчанию фокус стоит на моем элементе. При нажатии на TAB фокус переходит на кнопку. При дальнейшим нажатии на TAB по идее фокус должен возвратиться на мой элемент, но приложение зависает... В чем может быть проблема? Есть же еще у стандартных элементов свойство TabIndex, которые унаследованы от Control, а у меня его нет. может в этом проблема?
Re[4]: Фокус ввода
От: Аноним  
Дата: 20.04.11 12:31
Оценка:
public class MyElement : FrameworkElement
{
    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 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);
        }
    }
   
    // .............
}

Проблему не решило. Все равно виснет
Re[4]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 12:32
Оценка:
Вы смотрели на FocusManager?
Re[4]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 12:36
Оценка: +1
Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?
Re[5]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 12:45
Оценка:
Здравствуйте, DmitryMS, Вы писали:

DMS>Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?


Скорее, "на таком _низком_ уровне". А чем "базовее" базу выберешь, чем меньше классов в иерархии между тобой и выше будет, тем тем меньше будешь от этой самой базы зависеть.
Help will always be given at Hogwarts to those who ask for it.
Re[5]: Фокус ввода
От: Аноним  
Дата: 20.04.11 12:50
Оценка:
Здравствуйте, DmitryMS, Вы писали:

DMS>Вы смотрели на FocusManager?


Это типо такого?

 Panel panel = this.Parent as Panel;
 FocusManager.SetFocusedElement(panel, this);

Чего-то не помогло.
Re[5]: Фокус ввода
От: Аноним  
Дата: 20.04.11 12:58
Оценка:
Здравствуйте, DmitryMS, Вы писали:

DMS>Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?


Не нужны:

Template
TemplateCache
VerticalContentAlignment
BorderThickness
и т.д.
Re[6]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 13:26
Оценка:
Здравствуйте, _FRED_, Вы писали:

DMS>>Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?


>>FR>Скорее, "на таком _низком_ уровне".


DMS>>Что за бред Имелось ввиду уровне [абстракции]. "Знание предмета на низком уровне" оставляем в пэтэушном прошлом


>>FR>А чем "базовее" базу выберешь, чем меньше классов в иерархии между тобой и выше будет, тем тем меньше будешь от этой самой базы зависеть.


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


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

Наследоваться от FramworkElement's для своего визуального компонента (я не рассматриваю людей, предпочитающих наследоваться от object, на всякий случай — вдруг мощь где то утеряется?) смысла нет.
Re[6]: Фокус ввода
От: Аноним  
Дата: 20.04.11 13:31
Оценка:
Здравствуйте, Аноним, Вы писали:

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


DMS>>Вы смотрели на FocusManager?


А>Это типо такого?


А>
А> Panel panel = this.Parent as Panel;
А> FocusManager.SetFocusedElement(panel, this);
А>

А>Чего-то не помогло.

Проблема решилась следующей строчкой

 FocusManager.SetIsFocusScope(this, true);

А вот как реализовать TabIndex? выше изложенный вариант, который я скопировал из рефлектора, при просмотре класса Control, игнорирует значения свойства TabIndex
Re[7]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 13:34
Оценка:
IsTabStop == true?
Re[6]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 13:36
Оценка:
FrameworkElement — суть коннектор, даже мсдн советует наследоваться от Panel/Control.

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.
Re[8]: Фокус ввода
От: Аноним  
Дата: 20.04.11 13:41
Оценка:
Здравствуйте, DmitryMS, Вы писали:

DMS>IsTabStop == true?

Да
Re[9]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 13:53
Оценка:
kod kin'te
Re[6]: Фокус ввода
От: Sinix  
Дата: 20.04.11 14:07
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Скорее, "на таком _низком_ уровне". А чем "базовее" базу выберешь, чем меньше классов в иерархии между тобой и выше будет, тем тем меньше будешь от этой самой базы зависеть.


... и тем велосипедов можно будет переизобрести. И тем больше интересных граблей нащупать

Официальный гадлайн — интерактивные контролы должны наследоваться от Control.

Deriving from the Control class is the model used by most of the existing WPF controls
...
Consider deriving from FrameworkElement if any of the following apply:

— You want to have precise control over the appearance of your control beyond what is provided by simple element composition.
— You want to define the appearance of your control by defining your own render logic.
— You want to compose existing elements in novel ways that go beyond what is possible with UserControl and Control.


Вон ТС уже фокус переизобретает... ну-ну.
Re[4]: Фокус ввода
От: v.makeev Россия  
Дата: 20.04.11 14:18
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Теперь другая проблема получилась. На панели отобразил свой элемент и кнопку. По умолчанию фокус стоит на моем элементе. При нажатии на TAB фокус переходит на кнопку. При дальнейшим нажатии на TAB по идее фокус должен возвратиться на мой элемент, но приложение зависает... В чем может быть проблема? Есть же еще у стандартных элементов свойство TabIndex, которые унаследованы от Control, а у меня его нет. может в этом проблема?


Не в TabIndex'е счастье

// Да-да, абсолютно пустой класс
public class MyElement : FrameworkElement
{
}

...
private void SomeMethodOfWindow()
{
    var myElement = new MyElement { Focusable = true, IsEnabled = true, Width = 50, Height = 50 };
    grid.Children.Add(myElement);
}


Обрабатывает клавишу TAB абсолютно корректно. Возможно, какие-то составные части вашего элемента тоже пытаются обработать TAB.
WpfInspector вам в помощь
Re[7]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 14:27
Оценка:
Здравствуйте, DmitryMS, Вы писали:

DMS>>>Кстати, зачем наследоваться на таком высоком уровне как FrameworkElement, чем плох Control, если уж так хочется наследоваться?

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

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


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

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


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

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


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

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


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

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

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

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


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

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.


Уверяю вас, я внимательно читаю документацию. И не вижу тут указаний наследоваться от чего-то конкретного и не наследоваться от FrameworkElement. Даже мой плохой английский позволяет понять, что тут нет никаких указаний, а лишь совет о том, _что чаще всего_ нужно в _типовых кейсах_.
Help will always be given at Hogwarts to those who ask for it.
Re[7]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 14:34
Оценка: +2
Здравствуйте, Sinix, Вы писали:

_FR>>Скорее, "на таком _низком_ уровне". А чем "базовее" базу выберешь, чем меньше классов в иерархии между тобой и выше будет, тем тем меньше будешь от этой самой базы зависеть.

S>... и тем велосипедов можно будет переизобрести. И тем больше интересных граблей нащупать
S>Официальный гадлайн — интерактивные контролы должны наследоваться от Control.
S>

S>Deriving from the Control class is the model used by most of the existing WPF controls
S>...
S>Consider deriving from FrameworkElement if any of the following apply:

S>- You want to have precise control over the appearance of your control beyond what is provided by simple element composition.
S>- You want to define the appearance of your control by defining your own render logic.
S>- You want to compose existing elements in novel ways that go beyond what is possible with UserControl and Control.

S>Вон ТС уже фокус переизобретает... ну-ну.

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

Задумайтесь сами — перекрывает ли вышеотквоченное всё то многообразие, что может понадобится в жизни? Неужели скудный набор имеющихся наследников FrameworkElement может удовлетворить самые взыскательные, кои предъявляю я, требования? Ну-ну
Help will always be given at Hogwarts to those who ask for it.
Re[8]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 14:42
Оценка:
Вы сами себе противоречите, не находите?

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. Даже мой плохой английский позволяет понять, что тут нет никаких указаний, а лишь совет о том, _что чаще всего_ нужно в _типовых кейсах_.


Не сомневаюсь, но слон то бы и незамечен.
Re[8]: Фокус ввода
От: DmitryMS  
Дата: 20.04.11 14:49
Оценка: -1
Извините что влезаю, но вы мыслите антисистемно. Если вам хочется занайтся непродуктивным исследование fair play to you. Есть небезизвестный деятель из майкрософта, накатавший оду про причину co-existance of FramworkElement & FrameworkContentElement, вместо того чтобы признать — мы обосрались, please accept our applogies.

Вам определенно стоит его почитать дляупрочения доказательной базы.
Re[9]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 15:05
Оценка:
Здравствуйте, DmitryMS, Вы писали:

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


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


Спасибо, ваша доказательная база в моих коментариях действительно не нуждается. Остаётся надеяться, что и другим это видно.
Help will always be given at Hogwarts to those who ask for it.
Re[8]: Фокус ввода
От: Sinix  
Дата: 20.04.11 15:15
Оценка:
Здравствуйте, _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);
}


Что нам как бы намекает — полноценно сымитировать поведение контрола — дело неблагодарное
Re[9]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 16:02
Оценка:
Здравствуйте, 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>Что нам как бы намекает — полноценно сымитировать поведение контрола — дело неблагодарное

А кто вам сказал, что кому-то нужно "полноценно" ИМХО, именно от непонимания того, что там творится, рождаетсмя болезнь "это делать не нужно"
Help will always be given at Hogwarts to those who ask for it.
Re[10]: Фокус ввода
От: Sinix  
Дата: 20.04.11 16:52
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


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

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


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

_FR>Вы видели сколько наследников у FrameworkElement? Panel является по вашему "custom controls"?

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

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


Не, погодите! Или мы достаточно квалифицированы, чтобы лезть в дебри wpf (зачем _официально_ предлагается наследоваться от FE было в цитате выше), или мы делаем тяп-ляп контрол и в таком случае нам тем более пофиг, от чего наследоваться. И, раз уж топикстартеру _уже_ нужен функционал из Control — зачем играть в луддитов?
Re[11]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 17:33
Оценка: +1
Здравствуйте, Sinix, Вы писали:

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

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

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

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

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

В моём сообщении
Автор: _FRED_
Дата: 20.04.11
, на которое был дан ответ, нет ни слова о "у нас речь идёт о наследовании от FE ради избавления от "оверхеда"" А о том, на сколько большим оверхедом для топикстартера окажется то, что он задумал, опять же не нам судить. Нам очень сложно учесть все его кейсы и полностью его ситуацию и что бы возражать в таких остоятельствах треюбуется доказать, что нет таких кейсов, которые стоили бы наследования от FrameworkElement. Мне кажется, доказать такое будет затруднительно. По крайней мере, советы из MSDN не звучат убедительно.
Help will always be given at Hogwarts to those who ask for it.
Re[10]: Фокус ввода
От: Аноним  
Дата: 20.04.11 17:33
Оценка:
Здравствуйте, 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>


В итоге на мой элемент фокус приходит в последнюю очередь, хотя должен быть между кнопками.
Re[12]: Фокус ввода
От: Аноним  
Дата: 20.04.11 17:40
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


Я просто изучаю тонкости WPF(область попадания, Visual, стили, шаблоны) и решил воссоздать свой элемент(конечно урезанный). Появились трудности с фокусом и решил обратиться к Вам за помощью.
Re[5]: Фокус ввода
От: Аноним  
Дата: 20.04.11 18:24
Оценка:
Здравствуйте, v.makeev, Вы писали:

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


проблема была в следующем
Автор:
Дата: 20.04.11



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


Спасибо за софт — очень хороший!
Re[13]: Фокус ввода
От: _FRED_ Черногория
Дата: 20.04.11 19:36
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


Очень правильно сделали. Не просто представить все сложности "фокусов" не попробовав сделать их самостоятельно А на дебаты влкруг не обращайте слишком много внимания :о)
Help will always be given at Hogwarts to those who ask for it.
Re[12]: Фокус ввода
От: Sinix  
Дата: 20.04.11 23:59
Оценка:
Здравствуйте, _FRED_, Вы писали:

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


Ок, будем тщательнее придумывать дисклаймеры
Re[11]: Фокус ввода
От: DmitryMS  
Дата: 21.04.11 08:40
Оценка:
Кроме шуток, вы серьезно решили написать свою систему фокуса для того чтобы избежать овехеда вызванного использованием Control? Если это так, то посоветовать что либо вам мне, увы, нечего У дачи!
Re[11]: Фокус ввода
От: Аноним  
Дата: 21.04.11 08:44
Оценка:
Здравствуйте, Аноним, Вы писали:

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

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;
}
Re[12]: Фокус ввода
От: Аноним  
Дата: 21.04.11 08:51
Оценка:
Здравствуйте, DmitryMS, Вы писали:

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


Нет, не решил
Автор:
Дата: 20.04.11
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.